Under what circumstances will C++ fail to call an inherited class's constructor?

Question

EDIT following resolution, this has been substantially edited to dump irrelevant detail and explain the real issue.

I found a problem recently in some old code. The particular code was only rarely used and had insufficient unit tests (I was adding some more when I spotted the problem). I only relatively recently stopped using Visual C++ 2003, and symptoms didn't show in VC++9, only in MinGW GCC 4.4.0. And only release builds. And the symptoms vanished as soon as I added any trace code. Don't you just hate those?

Anyway, it turned out that the copy constructor and assignment operator overload weren't being called in all cases. As a result, a data structure was becoming inconsistent. Most of the time I was fluking through.

I spotted the issue by stepping through in the VC++9 debugger, even though the VC++9 build didn't show the symptoms. So, at least two compilers are behaving the same, even though the symptoms didn't show for one - a fair hint that the behaviour that caught me unawares is standards compliant, and I've been relying on old non-standard behaviour.

So... under what circumstances will the constructor etc for an inherited base class fail to be called?

FWIW, the problem code is part of the library that led to this question.

RESOLUTION

There were two separate issues - copy construction and overloaded assignment.

The copy construction issue turned out to be the well know return value optimisation issue, in the more recent "named" variant. The involved objects were "cursors" (like iterators) pointing into multiway tree leaf nodes. In order to ensure they are maintained, each leaf node keeps a linked list of cursors that refer into it.

The cursor is a very lightweight class - a leaf node pointer, a subscript within the node, and a next pointer for the maintenance list. The only reason that the explicit construction/destruction/assignment are needed is for the side-effect of maintaining the cursors lists.

Because the class is so lightweight, and because there are rarely more than a few cursors (and especially rarely more than one or two pointing into a particular leaf node), I sometimes used pass-by-value and return-by-value. The latter seems to be the problem.

Changing the copy constructor implementation accidentally bypassed this issue - I get the impression (unconfirmed) that for release builds, both MinGW GCC and VC++ still try to avoid bypassing copy constructors with side-effects, but miss some kinds of side-effects.

Second problem - the assignment overload. This, I think, was an old stupid mistake on my part, and if I hadn't had the copy constructor issue at roughly the same time, I'd have figured it out more quickly.

The assignment overload was inherited through two layers of inheritance, with some template, privacy and dependent-type complications along the way. Neither the middle nor derived class overrode it. This kind of makes sense (in an its-wrong-anyway way) in this special case - the derived class doesn't add any member data, it just supplies the template parameter to the base and adds some methods. But I'd be pretty surprised if the standard has special cases for "but i didn't add any member data".

With older compilers, I think I was fluking through on implicit casting rules allowing the base-class assignment operation to be called. I wouldn't like to try to trace the exact reason for the change in behaviour - the key point is that I'm being punished for writing some messy and bizarrely structured code.

Answer 1

The most important case is when it skips calling copy constructors entirely. This is a specific optimization that is allowed even in cases where the observable behavior changes.

Another case that catches some inexperienced developers is that unless specified otherwise, Derived::Derived(T) calls Base::Base() - not Base::Base(T)

Answer 2

Never. If you create a Derived class, then the Base class constructor will always be called. If you invoke the Derived destructor (assuming that you remembered a virtual destructor), then the Base destructor will also be called. From the point of view of constructors/destructors, inheritance doesn't behave any different to composition. What you're likely seeing in the above is a form of ellision. Your compiler decided that you never do anything with that value, and got rid of it.

Edit: Or as Neil says, you found undefined behaviour first, and it caused this to happen.

Answer 3

For a correct C++ implementation, this will never happen in correct code. If it does, you either have a compiler bug or your code has gone off into undefined behaviour land prior to the object construction because of bugs in your code. The latter is the most likely.