Blog posts tagged with: c-sharp

Forward declaring things in C++ is very useful because it dramatically speeds up compilation time. You can forward declare several things in C++ including: struct, class, function, etc...

But can you forward declare an enum in C++?

No you can't.

But why not allow it? If it were allowed you could define your enum type in your header file, and your enum values in your source file. Sounds like it should be allowed right?

Wrong.

In C++ there is no default type for enum like there is in C# (int). In C++ your enum type will be determined by the compiler to be any type that will fit the range of values you have for your enum.

What does that mean?

It means that your enum's underlying type cannot be fully determined until you have all of the values of the enum defined. Which mans you cannot separate the declaration and definition of your enum. And therefore you cannot forward declare an enum in C++.

The ISO C++ standard S7.2.5:

The underlying type of an enumeration is an integral type that can represent all the enumerator values defined in the enumeration. It is implementation-defined which integral type is used as the underlying type for an enumeration except that the underlying type shall not be larger than int unless the value of an enumerator cannot fit in an int or unsigned int. If the enumerator-list is empty, the underlying type is as if the enumeration had a single enumerator with value 0. The value of sizeof() applied to an enumeration type, an object of enumeration type, or an enumerator, is the value of sizeof() applied to the underlying type.

You can determine the size of an enumerated type in C++ by using the sizeof operator. The size of the enumerated type is the size of its underlying type. In this way you can guess which type your compiler is using for your enum.

What if you specify the type of your enum explicitly like this:

enum Color : char { Red=0, Green=1, Blue=2};
assert(sizeof Color == 1);

Can you then forward declare your enum?

No. But why not?

Specifying the type of an enum is not actually part of the current C++ standard. It is a VC++ extension. It will be part of C++0x though.

What are abstract functions?

Abstract functions, are functions who's implementation is not yet specified.

They are useful because:

• They allow you to define an interface without defining an implementation.
  
• A base class may not have a specific default definition for a function, but you know that derived types will.

In C++ both interfaces, and abstract classes are done via pure virtual functions. Pure virtual functions simply say that derived types must override the function. The base type can have a default implementation (that the derived types can use by calling the base function directly) but the base functions typically have no implementation at all.

In C# there are different constructs for interfaces (interface) and undefined base functions (abstract).

This post discusses what pure virtual function call errors are, and how they work across the following languages: C++, C#, and Python.

What is a pure virtual function call error?

Pure virtual function call errors could potentially happen, in a programming language that allows you to create partially implemented classes. Although not all programming languages can have pure virtual function call errors.

Pure virtual function call errors occur when a call is made to a pure virtual function. Since an abstract base type cannot be created in most languages, they will typically occur before a derived type is fully created, or after a derived type is already destroyed. The call is therefore usually called from the base type. Pure virtual function call errors could potentially also occur when using a pointer to call a function of an already deleted object.

Can C++ have pure virtual function errors?

Yes.

Consider the order of construction for the following C++ code:

class Animal
{
public:
  virtual ~Animal() {}
  virtual void Speak() = 0;
  Animal() {}
};

class Dog : public Animal
{
public: 
  virtual void Speak() { }
};

//.... 
Dog leia;

When you create an instance of Dog the following happens:

1. Construct Animal
2. Construct Dog

When the instance of Dog named leia falls out of scope, the following happens on destruction:

1. Destruct Dog
2. Destruct Animal

If you happen to call Speak() in the destructor of Animal, or in the constructor of Animal, then a pure virtual function error will occur. Most C++ compilers will give you a compiling error; however, you can get around this compiling error by calling a function that calls a pure virtual function.

Here is a code sample that will produce a pure virtual function runtime error in g++, Visual Studio 2005, and Visual Studio 2008.

class Animal
{
public:
    virtual ~Animal() {}
    virtual void Speak() = 0;
    void SpeakPlease()
    {
        Speak();
    }
    Animal() 
    {
        SpeakPlease();
    }
};

class Dog : public Animal
{
public: 
    virtual void Speak() { }
};

int main(int argc, char* argv[])
{
    Dog leia;
    return 0;
}

Can C# have pure virtual function errors?

No.

C# allows you to create pure virtual functions by using the abstract keyword on each of your abstract function/methods. And if you have even one abstract function/method in your class you must also use abstract before your class declaration.

C# gets around pure virtual function calls though, but arguably in a worse way.

public abstract class Animal
{
    public Animal()
    {
        Speak();
    }

    ~Animal()
    {
        Speak();
    }

    public abstract void Speak();
}

public class Dog : Animal
{
    public override void Speak()
    {
        Console.WriteLine("Woof!");
    }

    ~Dog()
    {
    }
}

Dog::Speak() will be called in the destructor of Animal even know Dog is already destructed. Obviously this can lead to many problems.

Can Python have pure virtual function errors?

Kind of, and only if you follow certain conventions.

Python can't define abstract functions directly, instead you simply raise an exception of type NotImplemented.

In Python all functions/methods are virtual.

This is to say pure virtual function support is defined in Python simply by convention instead of language constructs.

Therefore unlike C++ and C#, you can create objects of a class that have some of it's functions/methods as abstract. In that sence you can have pure virtual function errors (via NotImplementedError exceptions)

But Python works like C# in the sense that even before the derived type is constructed, it will call into it. The end result is that it throws an exception that can be caught.

class Animal(object):
  def __init__(self):
    print("Constructing animal")    
    self.Speak()
  def Speak(self):
    raise NotImplementedError
  def __del__(self):
    print("Destructing animal")

class Dog(Animal):
  def __init__(self):
    super(Dog, self).__init__()
    print("Constructing Dog")
  def Speak(self):
    print("Woof!")    
  def __del__(self):
    print("Destructing dog")
    super(Dog, self).__del__()

def Test():
  leia = Dog()

Next time you get an error like: "R6025 Pure virtual function call", perhaps you will wonder less about the source of the error.

I'm currently reading:

1. Gray Hat Python: Python Programming for hackers and reverse engineers by Justin Seitz
2. C# in depth 2nd edition by John Skeet

I'm about half way through both books. They're both great books so far.

exceptions