Hi Jim, Monty, Gary,
>>>>> 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.
As others have stated, I think everyone is in agreement here, except
for inline functions. There is no way around this really, and in some
cases it's certainly worth it (not all of course, we should not just
make assumptions and let numbers make that decision).
>>>> 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?
Constructor initializer lists should be perfectly clear to any C++
programmer. If not, it's worth taking the time to make it so. It
shouldn't really be a matter of preference, it's just the correct
thing to do.
> 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.
It's not just a matter of clarity, but also of performance and
correctness. For example:
class Foo
{
std::string& bar;
public:
Foo(const std::string& bar_arg):
bar(bar_arg)
{}
}
Is more efficient than:
class Foo
{
std::string& bar;
public:
Foo(const std::string& bar_arg)
{
bar= bar_arg;
}
}
In the second case, the default std::string constructor gets called,
than the copy operator is called. The first case only has the
constructor taking an argument. Remember a default constructor is
called for every member that has one before entering the body of the
constructor, and you want to avoid those double assignments.
> 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.
I agree, it has some ugly corners in it. The problem is writing in C+
(using only the less offensive parts of C++) is even uglier. You
should really just stay in C or take C++ in all it's glory. Doing
things just half way leads to inefficient and more problematic code.
> 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.
Maybe we should all switch to Java, throw out platform independence,
and help with more efficient native machine code compilers? :)
(not really joking here...)
> <rant on the technical quality of STL omitted in the interest of brevity>
<agree and rant on parts of the STL, but argues some things are useful>
Yes, you need to be picky.
Best regards,
-Eric
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
