Nullable is a value type

It’s a struct that can be null. The only reason why int? intVal = null; compiles is because C# compiler supports nullable types. You cannot define the same kind of struct yourself.

The decision to make Nullable<T> a value type actually makes sense if you think about it. Calling its member methods and properties will always succeed, i.e. NullReferenceException will never be thrown. This gurantees that HasValue never throws a NullReferenceException.

Comparison to null

Under the hood, the compiler, in fact translates comparison to null to a call to HasValue. The below MSIL demonstrates that:

    .locals init ([0] valuetype [mscorlib]System.Nullable`1<int32> 'value',
           [1] bool hasvalue,
           [2] bool hasvalue2)

    //int? value = null;
    IL_0001:  ldloca.s   'value'
    IL_0003:  initobj    valuetype [mscorlib]System.Nullable`1<int32>
    //bool hasvalue = value.HasValue;
    IL_0009:  ldloca.s   'value'
    IL_000b:  call       instance bool valuetype [mscorlib]System.Nullable`1<int32>::get_HasValue()
    IL_0010:  stloc.1
    //bool hasvalue2 = value != null;
    IL_0011:  ldloca.s   'value' //loads a variable onto evaluation stack
    IL_0013:  call       instance bool valuetype [mscorlib]System.Nullable`1<int32>::get_HasValue() //calls HasValue
    IL_001b:  stloc.2 //Stores the result in location 2 (hasvalue2)

As you can see the generated IL for hasvalue = value.HasValue and hasvalue2 = value != null are identical.

null Assignment

Also from above code you can see that assigning null to a nullable value is the same as calling the parameterless contructor (which all value types have).

Ternary operator

C# compiler also does special things with ternary operator for nullable types. The following code compiles:

int? nullableIntVal = 4;
int intVal = nullableIntVal ?? -1;

The above is just syntactic sugar for calling HasValue and if it’s true calling GetValueOrDefault(). The compiler actually generates a temporary variable to call HasValue off in both Release and Debug modes. Not sure why that is. Below code illustrates the equivalent C# code to what the compiler generates for ternary operator.

int? nullableIntVal = 4;
int? temp = nullableIntVal;
int intVal = temp.HasValue ?? temp.GetValueOrDefault() : -1;

Summary

Nullable<T> is a special value type that has support from C# compiler to allow the following:

• null assignment – under the hood: calling defualt constructor.
• null comparison – under the hood: calling HasValue property.
• ternary operator ?? – under the hood: calling HasValue and conditionally GetValueOrDefault.

void c_rtti::foobar(a_rtti & a2) {
   c_rtti* c_ = dynamic_cast<c_rtti*>(&a2);
   if (c_) {
      ::foobar(*this,*c_);
      return;
   }
   b_rtti* b_ = dynamic_cast<b_rtti*>(&a2);
   if (b_) {
      ::foobar(*b_, *this);
   }
}

I have used the most non-trivial case where the above function is called with a2 parameter pointing to an instance of b_rtti, thus triggerring two dynamic casts. I used the same technique on the vtable implementation for consistency, although it doesn’t matter as the sequence of execution is the same for any combination of objects. The test ran for 4 million iterations.

Here is the test code:

        a& a_ = c();
        b bInstance;
        a& b_ = bInstance;
        a_.foobar(b_);

Just to show what actually happens in both implementations, here are the sequence diagrams.

vtable:

dynamic_cast:

The results

In debug mode, RTTI implementation is about 20% faster:

No RTTI - 1685 milleseconds.
With RTTI - 1295 milleseconds.(23.15% faster)

So this is pretty insignificant in a real life application and I doubt it would come in the profiler. By my calculation there is about 100 clock cycles (on a 1Ghz CPU) difference between the two per call.

In Release mode things get interesting:

No RTTI - 62 milleseconds.
With RTTI - 780 milleseconds.(-1158.06% faster)

The pure vtable version is ten times faster!!! Of course this again means very little in the real world. It’s worth noting that the RTTI verson is twice faster in Release mode. What is also interesting is that in Debug mode vtable is slower by 100 clock cycles, in release it’s faster by 200.

To summarise. The real life value of this performance analysis is zero. If you are Google and you had 100 PhDs design the program and another 100 wrote the library routines for it, doing this optimization will improve the performance by about 0.000001%. In any other case, this is textbook case of premature optimisation.

So the trick to get this working as pointed out in the article was to call the function on the pointer or reference of the parameter to the original function, thus cauising a second dispatch.

class A {
  virtual void PublicFunction(B& b) {
    b.PerformFunction(*this);
  }
}

The problem with doing this sort of thing with subclasses of the same base is that we need to allow the possibility of the base class being called with one of its subclasses as a parameter. Luckily we can use forward declarations to define the functions and implement them later on.

class b;
class c;
class a {
protected:
    virtual void doFoobar(a& a2); //do stuff here 
    virtual void doFoobar(b& b2); //delegate to b
    virtual void doFoobar(c& c2); //delegate to c
public:
    virtual void foobar(a& a2) {
        a2.doFoobar(*this);
    }
    friend class b;
    friend class c;
};
class b : public a {
protected:
    virtual void doFoobar(a& a2); //do stuff here 
    virtual void doFoobar(b& b2); //do stuff here
    virtual void doFoobar(c& c2); //delegate to c
public:
    virtual void foobar(a& a2) {
        a2.doFoobar(*this);
    }
    friend class a;
};
class c : public b {
protected:
    virtual void doFoobar(a& a2); //do stuff here 
    virtual void doFoobar(b& b2); //do stuff here
    virtual void doFoobar(c& c2); //delegate to c
public:
    virtual void foobar(a& a2) {
        a2.doFoobar(*this);
    }
    friend class a;
    friend class b;
};
//class a
void a::doFoobar(a& a2)  {
    printf("Doing a<->a\n");
}
void a::doFoobar(b& b2)  {
    b2.doFoobar(*this);
}
void a::doFoobar(c& c2)  {
    c2.doFoobar(*this);
}
//class b
void b::doFoobar(a& a2)  {
    printf("Doing b<->a\n");
}
void b::doFoobar(b& b2)  {
    printf("Doing b<->b\n");
}
void b::doFoobar(c& c2)  {
    c2.doFoobar(*this);
}
//class c
void c::doFoobar(a& a2)  {
    printf("Doing c<->a\n");
}
void c::doFoobar(b& b2)  {
    printf("Doing c<->b\n");
}
void c::doFoobar(c& c2)  {
    printf("Doing c<->c\n");
}

The code is far from an ideal double dispatch solution as it relies on the forward declaration trick to resolve the circular dependency between the subclasses. This means that all the classes that need to have this functionality must be known at compile-time (of the base class). This means the base class cannot be made into a library component.

To explain all the friend declarations. Considering the fact that all the classes a, b and c are tightly coupled as is, I added friend declarations so that the actual worker function is private and cannot be called from the outside.

Most of the time I realize that a lot of those pattens is osmething that I have been doing for years without thinking. In fact this inspires me to go through “the list” of all the patterns and do a series of blog posts – “Design Patterns – What you have coded for years is actually an idiom – [insert design pattern here]“.

So, I only just recently found out that the practice of using smart pointers is officially called RAII – Resource Allocation Is Initialization. The Wikipedia article bangs on about ojects being allocated on the stack and exception safety, but in my opinion those considerations are not as significant as the magic of destruction.

The only way this works in C++ is due to deterministic destructors. The magic happens upon destruction, not upon initialization. Any garbage collected language can have Allocation on Initialization, but they can’t guarantee implicit destruction when going out of scope like C++ does.

I also think that that object scope (the fact that it should be on the stack) is somewhat peripheral again. The destructor will get called whenever you explicitly delete the object as well. Whilst this is not strictly automagic destruction, it can be – for example when using collections that are aware of element removal semantics. For example a collection might either call a Release method on a ref counted object or call operator delete on plain old pointer.

So this brings me back to the title of hte post – shouldn’t Resource Allocation Is Initialization be Resource Deallocation Is Destruction? That’s where the magic happens, right?