[lug] new operator in C++

[Tom Tromey]

>>>>> "Peter" == Peter Hutnick <peter-lists at hutnick.com> writes:

Peter> Isn't initializing /everything/ within the code the only
Peter> responsible thing to do?  Preferably to a logical nonsense
Peter> value that you can easily test for?

It depends on your program and your environment.

For instance, in Java all fields are given initial values.  So in Java
one typically would not initialize fields where the default value is
correct.

In C you might not want to initialize things if some particular
function is very performance-critical.  The number of such functions
is much smaller than the number of times you'll see this done,
unfortunately.

Peter> It seems to me that compilers are surprisingly inconsistent,
Peter> and that if the g++ test had shown that the memory was zeroed
Peter> out it would only prove that you could rely on that particular
Peter> version of g++ on that particular platform to zero those values
Peter> out.

It is very important to know the language definition for any language
you're working with.  That helps when you want to differentiate
between what "works here" and what "should work everywhere".

For some languages, notably C++, you also have to be very familiar
with the actual practice.  C++ has a long and ugly history of the
language standard being years ahead of all available compilers.  This
*still* seems to be a reason to be wary of C++ :-(

Peter> At the risk of getting on a philosophical tear, it seems like
Peter> initializing memory is something that a compiler "shouldn't"
Peter> do.  What is the advantage?  The odds of the compiler
Peter> initializing to what ends up being a "good" test value for
Peter> unset variables for your particular use is about nil.

In Java initialization has nothing to do with picking a good value for
the programmer.  Instead it is about safety.  If fields were not
initialized by `new', then it might be possible to write programs that
crashed the VM.

Local variables in Java aren't initialized, because Java has rules
("definite assignment") to decide whether a given variable can be used
before it is initialized.  This is possible with local variables (in
Java), but not with fields (or at least, not as easily).

These decisions are all tradeoffs.  Java has a lot of features that
make it easier to program.  And, in fact, our experience with gcj is
that Java is much easier to use (than C or C++) in some respects.  For
instance, when working on libgcj we generally only need to test Java
code on one platform (there are exceptions); we know it will work
everywhere.  For C and C++, things aren't nearly so rosy.  People
spend a lot of time writing things like memory checking tools for C
and C++; these tools are literally useless in the gcj context (you
can't leak memory, overrun an array, or see an invalid pointer).  On
the other hand, the gcj user pays for these features in performance
(sometimes).

Tom