Monty Taylor wrote:
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) {}
It's more clear because a) assignments should look like assignments, b)
not all initialization code fits in parameter initialization, and c)
code executed in a block should be in one place.
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.
It's even easier to use constructors as constructors and not use a wart
in the C++ language as if it buys something. It doesn't. Using the
initialize list to pass parameters to a superclass constructure is
necessary. So is initializing members that can't be initialized any
other way. But by and large, code is code, and code belongs in clearly
executable blocks.
I like C++. It is my language of choice. I write nothing but OO code
in it. But C++ is a grotesque, obese, pig of a language that resulted
by trying to graft objects onto C with a preprocessor. Used sparingly,
C++ is a workable language. If, as is often the case, you try to use
every horrible feature in the language, you code is going to look as
horrible as the C++ BNF.
It is my humble opinion that no one should be allowed to write C++ code
until he or she has demonstrated proficiency in Java. The Java guys got
it about right. If you use a subset of C++ roughly corresponding to
Java + delete and destructors, C++ is a very effective language.
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.
<rant on the technical quality of STL omitted in the interest of brevity>
--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
