C++ was a boon for technical interviewers. There was a time when C++ was about the only viable object-oriented programming language in a business environment. In those days you pretty much had to know C/C++ to be an OO programmer. So you could test someone’s depth of C++ knowledge (and thus their overall suitability) by just asking about all the messed up edge cases that make C++ really tricky to use.

Today we’ll be observing a hypothetical candidate Phil. Phil has been a C++ programmer for 5 years (2 of which were at University) and has rated himself 9/10 on the C++ confidence scale that I asked him about at the beginning. I’ve been talking to Phil about the various ‘overloaded’ meanings of the keyword virtual in C++. Phil has correctly answered what a virtual method was, but couldn’t get the one about the virtual base class.

Even so, Phil is now into his stride and feeling pretty good about himself, so then I lay it on him:

Phil, is it possible to ever call a pure virtual method?

To which Phil (and about 95% of other candidates) would heartily reply “No”. And of course Phil would be wrong. But that’s ok. First I want Phil to tell me why a pure virtual method can not be called usually. This demonstrates a basic understanding, and then I would try and probe to see if Phil can guess the correct answer as to how a pure virtual method can be called and then the reason it’s possible.

So, what?

If Phil didn’t get the answer straight away then Phil probably won’t get it at all. This is not terribly surprising I suppose, and it’s not a reason to reject Phil. The sad truth about being a C++ programmer is that you really need to know how C++ works, at some level, to be able to use it effectively. I’m here to find out what Phil’s level really is. The more oppurtunities I give him to tell me about those edge cases the better I can assess how good a (C++) programmer he is.

How?

So here is a code sample that under a couple of compilers (VC++ 2005 – Express, and GCC 3.4.4) produces the (un?)desired behaviour. I wanted to try it under some more recent C++ compiler invocations but don’t have them available on the machine that I’m writing this. Anyway, these two compilers seem fairly representative of what a lot of people are currently using.

#include<stdio.h>

class A {
protected:
	virtual void Reset() = 0;
	void Init()	{
		Reset();
	}
public:
	A()	{
		Init();
	}
};

class B : A {
protected:
	void Reset() 	{
		printf("Reset");
	}
public:
	B() {
	}
};

int main(int argc, char** argv)
{
	B b;
}

And here is the result:

$ g++ pvirt.cpp
$ ./a.out
pure virtual method called
      9 [sig] a.out 180 _cygtls::handle_exceptions: Error while dumping state (p
robably corrupted stack)
Segmentation fault (core dumped)

So for those, like Phil, not fully aware of the vaguaries of calling pure virtual methods here is the explanation.

Pure virtual methods can be called from base-class constructors that attempt to indirectly call pure virtual methods.

The reason it's a problem is that C++ constructs objects inside-out, so base classes get built before derived classes. If you then try and call a virtual method on a partially constructed object you will end up calling the base class copy of the virtual method. This is because at the time you are in the base-class constructor the object is of type base-class and not of type derived-class. Calling pure virtual methods from constructors sounds like a really bad idea then, and it is. But there might be legitimate reasons to want to do it, which I'll come to in a minute.

Note that if you try and call the virtual method directly from the constructor, like so:

class A
{
protected:
	virtual void Reset() = 0;
public:
	A()	{
		Reset();
	}
};

You will probably get a linker error because Reset() is pure and has no implementation, as you'd expect.

Why?

So why might you want to do this at all then? Well say you have a class hierarchy of objects that connect to a database for example.

So you dutifully create a Database base class with MySQLDatabase and OracleDatabase derived classes. Now when you disconnect an already established connection you need to reset all the structures as if they had just been created. The object is then ready to be reconnected. So you create a virtual Reset() method in the base class that does this. At the base level though this class should do nothing and you decide that your derived classes must define such a method so you very cleverly make it pure. You could then (but you probably wouldn't) write code like this:

void Database::Disconnect() {
	Reset();
}

And have the derived class handle the gorey details of the reset. You want the same behaviour when you create a new object so you simply add the Reset() function to the Init() function that you created to deal with the fact that you had to write so many different types of copy constructor in C++! Hey presto pure virtual method called.

Note that if you had decided not to make the method pure and just put in an empty stub then this empty stub would be called instead (and not the derived version). In some ways this is a harder error to track because there is no error just a silent refusal by the object system to call the derived version because it can't, because it doesn't exist yet.

The correct way to deal with this, unsurprisingly, is to not call Reset() from the base-class Init() function but from the derived constructor directly.

Phil

Thanks for coming Phil, we'll be in touch.

Anyway, as you’d expect from a magazine dedicated to C and C++ users it occasionally has articles about C and C++. This quarter’s doozy is from a chap we’ll call Stuart. Now it looks like some of the things that Stuart is doing for his PhD are quite interesting. However his article about the similarities he has managed to draw between Haskell and using partial-template specializations in C++ gives me the shudders. It is based, in part, on the work of Andrei Alexandrescu. As charming as Mr Alexandrescu is in person I wouldn’t let him anywhere near any of my production C++ code (if I had any). But that’s beside the point.

Now I have to admit that I don’t know any Haskell and I’m also not a lover of C++ much either so I can’t bring myself to actually RTFA. However the article is full of little code snippets like this:

    template <typename T> struct Head;
    template <int x, typename xs>
       struct Head<IntList<x,xs> > {
       enum { value = x };
    };

    template <typename T> struct Tail;
    template <int x, typename xs>
       struct Tail<IntList<x,xs> > {
        typedef xs result;
    };

Why anyone would hate themselves enough to actually do this and write about it I don’t know. Especially when you could just use Haskell and not have to wrap your head around this lunacy.

But I know there is a simple answer. I should just unsubscribe from the magazine if I don’t like it. But sadly for me it’s not that simple. Stuart is obviously a clever guy, it almost goes without saying. But he’s wasting his brain cycles. Surely he must have better things to do with his time.

Then I read this 2005 interview with the glorious Alan Kay. If you have the time I suggest you read all of it because he makes some really very excellent points. In reference to my pain though this one stands out:

Perhaps it was commercialization in the 1980s that killed off the next expected new thing. Our plan and our hope was that the next generation of kids would come along and do something better than Smalltalk around 1984 or so. We all thought that the next level of programming language would be much more strategic and even policy-oriented and would have much more knowledge about what it was trying to do. But a variety of different things conspired together, and that next generation actually didn’t show up. One could actually argue—as I sometimes do—that the success of commercial personal computing and operating systems has actually led to a considerable retrogression in many, many respects.

You could think of it as putting a low-pass filter on some of the good ideas from the ’60s and ’70s, as computing spread out much, much faster than educating unsophisticated people can happen.

And while Stuart carries on trying to make C++ like Haskell, rather than just using Haskell, another wasted brain drops into the soup.

To say I was anti-templates would be too strong. I find the code they produce hard to follow, regardless of how elegant and efficient they really are. But then they do serve a really useful need. Obviously containers are an example of something where templates are indispensable. So you can’t just write them off.

But now that we have the standard library (and boost) do mere mortals really need to worry or bother about templates in the large? I think the answer to this is probably no.

But then again it depends on what you’re doing. And since I’ve started working on writing a wrapper around the TIBCo/RV library for Ruby I found myself writing a lot of C++ code that was very similar apart from the types involved. So then a little light bulb goes on in my head (40w supermarket own brand, cliche retardant) . Surely I can write a template to do this for me? This will mean that there’s only one code base for a bunch of similar behaviour and when I need to write that internationisation add-on (i18n) for my error messages I’ll only need to change one or two methods instead of a zillion.

So I did the only honourable thing. I broke out my trusty Stroustrup 2nd edition. Found the footnote about templates. Grok’d the syntax again and I was away. Shortly after I realised that in one of functions the integer processing needed bounds checking and the floats didn’t/couldn’t. So I needed some different behaviour for float’s and int’s. So, what I really needed now was some function templates that explicitly did something for floats and treated everything else the same. Great, no problem. Explicit instantiation is your friend. Add a dash, mix well, retire.

The interesting part, at this point, was that I’d arrived in a new place. A place where perhaps templates weren’t so bad after all. So then I got to thinking what I really needed was code that could distinguish between signed and unsigned integers at compile time and surely there must be a way to do that. And maybe if I partially specialise this function a bit and explicitly specialise that one a bit it will just magically work.

Since the project I was working on thus far had been written without the benefit of real objects I decided at the begining I only needed function templates to do the job. Now to recap, I have just discovered that I needed partial specialisation of those templates to do different things for signed and unsigned ints. Well like I say, no-one was as surprised as me to find myself here.

But as so often happens with C++ it’s always ready to kick you in the balls at any moment. I couldn’t get the expected (guessed) partial function specialisation syntax to work. So, a quick search of the web sought out this jewel that was predicatbly written by the man Sutter which explains the situation in depth. Now I’m not going to rehash Sutter’s explanation. He does it well, so there’s no need.

But it’s like a drug, the next step would be to either use plain old functions (not possible in this case) or change my function templates into class templates to avoid the issue. And before you know it you’ve just stepped a little further away from the target … sometimes this is a good thing and sometimes it’s a bad thing. But with C++ you’ve got to watch it because before you know it you’ve templatized every living thing and no-one, not even god can tell you what you’ve done to yourself.

C++ is a weapon. The US military probably wants to classify it as lethal. But then they’d probably end up killing Europeans with it, dude.

Sometimes you’ve got to sit back because the solution is far more complicated than the problem it solves. And so I’m sitting back. I’m good at that. Very good indeed.