From: "Alisdair Meredith" <alisdair.meredith@uk.renaultf1.com>
Rob Stewart wrote:
I fail to see how relying on behavior of the language is not having sympathy for those reading the code. This is akin to explicitly invoking a default base ctor in an initializer list in my mind.
Explicit is good.
Sometimes.
Consistent is also good.
Unless it isn't. (I *am* a big fan of consistency but, "A foolish consistency is the hobgoblin of little minds," as Emerson put it.)
Consider:
struct base { double a; };
struct derived1 : base { derived1() : base() {} };
I'd never invoke the default constructor of what was supposed to be POD. Indeed, doing so invokes default-initialization which is counter to the norm. Thus, not invoking the default ctor in the initializer list is better as I was making the case for previously.
struct derived2 : base { derived2() {} };
Which of the 2 derived classes do you think is more subtle? derived1, which initialized base so member a == 0.0, or derived2 which does not initialize base, so a could be anything including a troublesome NaN.
The former. It requires one to realize that it is invoking default-initialization and it "uglifies" the initializer list with the invocation of a default constructor. However, I don't care for the latter either.
Which would you rather call attention to by breaking with convention?
Neither. I'd write this: struct derived3 : base { derived3() { a = 0.0; } };
And how many 'typical' C++ programmers do you believe are even aware of the difference?
Few. Thus, derived3 is superior.
Relying (un-necessarily) on subtlety in the language, and trying to second guess whether it was intended or not, is generally a hard way to share code and an invitation for trouble in a shared-source environment.
static initialization is hardly a subtlety of the language.
This thread is also heading off topic for a Boost list and would be more at home in comp.lang.c++.moderated.
Reasonable. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;