Jim Starkey wrote:
> Monty Taylor wrote:
>> Gary Pendergast wrote:
>>
>>> Hi folks,
>>>
>>> Here's something I've been running into occasionally:
>>>
>>> class Foo
>>> {
>>> int whee;
>>> public:
>>> Foo() : whee(10) {};
>>> }
>>>
>>> I just spent far too long debugging a problem that should have taken 2
>>> minutes, because I didn't realise 'whee' was being set in the class
>>> declaration.
>>>
>>> Personally, I'm a fan of "no program logic in the .h files at all", but
>>> I'm not sure if this topic has been discussed at all.
>>>
>>
>> Well... a couple of things here.
>>
>> It's definitely preferred to use initializers like above. Whether that
>> code is in .h or .cc is sort of up to judgment.
>>
> Why? Isn't it a great deal clearer to put the initialization code in
> the constructor? There certainly is any different in code size or
> speed, so why not go for clarity?
>
> An exception, of course, is a class member that itself requires a
> parameter for initialization.
Why is this:
FooConstructor()
{
x= 1;
}
any clearer than:
FooConstructor() : x(1) {}
The second is standard C++ and should be quite clear to anyone as to
what is going on. (or am I misunderstanding what you are saying here?)
Unless there is something that just must go in the constructor body (for
instance a pthread_init() call), member initialization should go in the
initialization list. We will, eventually, be turning on the gcc warning
that will carp about this. (-Weffc++) Meyers makes a good point about
this... to paraphrase, since there are some members that _must_ be done
in the initializer list (const members or references) it's a cleaner
policy to just always use the list rather than asking everyone to
memorize when things must and when things merely can.
>> The nice thing about putting some (especially smaller) pieces of code in
>> the headers is that it can be inlined elsewhere. So while I agree with
>> you in theory from a code cleanliness perspective, from a practical
>> perspective we wind up with a pretty decent amount of code in the
>> headers.
>>
> Basic sanitation dictates that code (other than inlines) belongs in
> implementation file. Headers are for declarations. The alternative is
> a rats nest like MySQL where inclusion of virtually any header brings in
> just about everything. You might was well have a single gigantic header
> and be done with it.
Totally agree. All code that is not intended for inlining should be in
implementation files.
I _was_ going to turn on the warning about code that you are declaring
for inlining (any code you put in a class declaration being
automatically declared such) not being viable inlining choices so we
could force even more code removal from headers, but the warning doesn't
ignore code coming from system headers and therefore throws
false-positives from STL headers. Doh.
Monty
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
