I’m back! As always, I had a delightful August visiting friends and relatives in Canada. It was even more fun than usual because I’ve got a new boat. That is, a new-to-me boat; the boat is almost as old as I am. It’s a 1976 avocado-green Hobie 16. Here’s a video I shot of my first time trying it out: (I recommend watching it in HD resolution.)
Well enough chit-chat, back to programming language design. Today on the Coverity Development Testing Blog’s continuing series Ask The Bug Guys I’ll discuss how C++ is like a discredited theory of evolutionary biology and why that means you should not call a virtual method in a constructor.
As always, if you have questions about a bug you’ve found in a C, C++, C# or Java program that you think would make a good episode of ATBG, please send your question along with a small reproducer of the problem to TheBugGuys@Coverity.com. We cannot promise to answer every question or solve every problem, but we’ll take a selection of the best questions that we can answer and address them on the dev testing blog every couple of weeks.
Fabulous adventures in coding 
Pingback: What is up with transparent identifiers? Part two | Fabulous adventures in coding
Was waiting to see you tack : )
Which lake?
I cut out the tacks and gybes as they were not actually that interesting from those angles. I’ve been looking at other ways to mount the GoPro on a Hobie and I think what I will do next time is mount the camera on a pole guyed between the jib tack and the dolphin striker. That way the camera looks back on the whole boat, which makes it much easier to see the entire manoeuvre.
It’s Lake Huron, on the Canadian side.
Great action video! What music is that? What about mounting the GoPro on the top of the mast so you can see the Hobie and it would be a good view of the waves? Is the video file compressed when added to your blog?
Mess JB, the music is free music I found on YouTube. I do plan to build a mast-top mount next year as well as a mount on a pole that I can guy forward of the boat. YouTube hosts the video and yes, they do compress it somewhat. Sorry we didn’t see you this year!
Oh Boy! That video brings back memories of sailing a cat around Mission Bay in San Diego in the 70’s. Dumped my girlfriend into the bay with that baby. She was…how shall I put it? …not down with that adventure. Thirty-five years later I send my thanks to the anonymous fellow in the power boat for flipping her sail side up again!
I have an International 14 in Seattle which is a Very Tippy Boat; I’ve capsized my wife into Puget Sound one too many times and she won’t go out on it. But she likes the Hobie.
I didn’t know that about C++.
Yeah, bad move in Java too, unsurprisingly. It’s compounded by the fact that every method is virtual, so you really ought to only call private helpers on a non-final (unsealed) class.
Although, that said, I did once see some code that was doing this without changing it. I verified that it was correct given the behaviour of the child classes it had (at the time) and cursed the person who had arranged the class hierarchy that way. Rearranging the class hierarchy and the methods concerned would have been prohibitively costly, given that the code as it was was only bug-prone, not actually buggy.
Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1687
Pingback: Dew Drop – September 4, 2014 (#1848) | Morning Dew
If some operation needs to be performed before control returns to the code which called the outermost constructor, and such operation requires the cooperation of the derived classes, how can that reasonably be accomplished other than by having the inheritance contract either specify that every class must ensure that certain virtual methods are usable before they call their base constructor (even if accomplishing that would–in the current version of C#–require icky use of ThreadStatic variables due to the inability of derived classes to store constructor parameter values into instance fields before calling the base constructor), or else by requiring that object instances only be constructed through use of factory methods which would then need to be re-implemented in every derived class? I’ll admit that having a base class constructor call a virtual `Initialize()` and requiring that subclasses support at least some other virtual methods between the time they return from that and the time their main constructor gets to run is somewhat inelegant, but requiring factory methods for everything is ugly too. Do better alternatives exist?
If it hurts when you do that, don’t do that. By “that” I could mean your specific scenario: simply don’t design classes that must do something interesting before full construction is done; rather, design classes where constructors initialize fields and that’s all.
By “that” I could also mean more generally the scenario where the graph of inheritance relationships and the graph of logical dependencies between components have lines that cross. A base class that depends on its derived class doing something right is a dangerous base class.
By “that” I could also mean inheritance in general. Inheritance is a massively overused and overhyped mechanism. I often find deep, complex inheritance hierarchies to add more complexity than they remove.
Another alternative would be a two-stage initialisation – the constructor sets member variables and the complex, type-hierarchy dependent stuff is done by an Initialise() method called afterwards. This obviously still sucks and would be best hidden in a factory method and/or documented clearly in comments.
I agree with Eric, the desire to do this would prompt me to re-examine my hierarchy and work out what was wrong that was requiring me to do this.
Two-stage initialization is actually quite common. Think new SqlConnection() followed by connection.Open(). This combines nicely with a common design pattern, where you call a parameterless constructor, followed by setting properties.
Not only is this quite common, it often turns out to be easier to use than complex constructors with many parameters.
That being said, setting properties obviously doesn’t work for immutable objects. That’s where the builder pattern comes in, another form of two-stage initialization. The builder is mutable, and has a method that returns an immutable object.
Yes, it might be a common pattern, but I think it sucks and I avoid it wherever possible. There are too many problems with half-constructed objects and problems forgetting to call something and – most especially – people not documenting the fact that some method call is required to make the thing go.
The builder pattern is great – avoids complex constructors, allows immutable objects, and still makes it clear when you are setting the thing up and when the thing is ready to use.
An API requirement to use two-stage initialization is a common workaround for the lack of a good means by which base-class constructors can perform two-stage initialization themselves. If an object will have an invariant which must be established before it can be used for anything, and will remain valid unless or until the object is rendered permanently useless, then from a semantic perspective that invariant really *should* be set in the constructor. The builder pattern improves semantics somewhat (if fooBuilder class contains a virtual factory method which creates a baseFoo, then a derivedFooBuilder:FooBuilder can override it to create a `derivedFoo`, and the `baseFoo` constructor can accept a `fooBuilder` class and pass it to a virtual `initialize()` method, thus allowing derived class to use its parameters without giving up the ability to ensure that additional startup logic is performed after that), but it can be a little awkward.
Otherwise, while exposed two-stage initialization may be the best way to work around the lack of internal two-stage initialization, it means that a reference of type `foo` will in some contexts be used to identify an object which only supports `Initialize()`, and in other contexts to identify an object which supports everything but `Initialize();`. Having one type support two disjoint sets of functionality at different points in its lifetime doesn’t seem like sound object oriented design. [The fact that objects which are disposed often don’t support any functionality does not represent a design problem, since code shouldn’t hold any references in any context where anything would try to do anything with them except perhaps call `Dispose` again].
agree
In the midwest, it’s usually said as, “Kernology recapitulates corntogeny.”