Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!samsung!rex!ames!elan!tom
From: tom@elan.Elan.COM (Thomas Smith)
Newsgroups: comp.lang.c++
Subject: Re: Why no renew
Message-ID: <966@elan.Elan.COM>
Date: 19 Mar 91 20:46:06 GMT
References: <1991Mar16.172814.6525@mathcs.sjsu.edu>
Organization: Elan Computer Group, Inc., Mountain View, CA
Lines: 62

horstman@mathcs.sjsu.edu (Cay Horstmann):
> In article <184@heurikon.heurikon.com> daves@ex.heurikon.com (Dave Scidmore) writes:
>>In article <1991Mar14.042611.14921@mathcs.sjsu.edu> horstman@mathcs.sjsu.edu (Cay Horstmann) writes:
>>>
>>>I repeat my request that operator new should default to initializing the
>>>memory with the logical 0 value for the type allocated (almost always an
>>>all-0 bit pattern, but then who knows how 0 pointers or 0.0 floats are
>>>represented on some crazy systems.) ANSI, are you listening?
>>
>>I think that *not* zeroing out memory should be the default. My reasons are
>>as follows: 
>>
>>	1) Zeroing is infrequently needed and seldom even helpful.
> 
> Huh? When you say X** a = new X*[100], isn't it most likely that you want
> all those X*'s to be null pointers?

No.  You're array might be null-terminated - in other words, you might do
    X** a = new X*[10000];	// notice the extra zeros
    a[0] = 0;			// initialy empty - null first object
The extra effort supplied by the compiler second-guessing what I the
programmer intended to do is wasted effort.  Furthermore, you may be
allocating the array to be large enough to handle a possible extreme case
in your program, rather than normal cases, thus it may need to be much
larger than 100.  Zeroing out 10s or 100s of thousands of bytes is not
a trivial operation efficiency-wise.

> I really don't envy the ANSI people. I thought that my suggestion of initia-
> lizing arrays of non-class type obtained from ::operator new was the most
> harmless and innocuous suggestion. It breaks absolutely no old code.

For those of us actually developing products, "breaking code" is read as
"taking a program with a certain behavior and changing it for the worse".
Slowing down a program a perceptable amount by doing something beyond
the control of the programmer certainly meets this description.

> Let me put this in perspective. If you want to allocate an array of 100
> ints or pointers and for some reason don't want them initialized with 
> zeroes, you can always use malloc. But if I want to write a template which
> allocates an array of X (maybe a class, maybe a basic type or a pointer),
> I cannot (at least with the ARM syntax) ask the template whether X is a class
> and either call new X[...] or calloc( sizeof(X)*... ). 

But you also said earlier
> I was talking about new applied to NON-CLASS TYPES. They don't have
> a constructor.

In other words, there isn't any benefit in initializing objects
that were due to be constructed (or possibly not), because that would be
wasted effort.  Your "template" example above contradicts this.
Instead of adding wasted overhead for many legitimate algorithms, you should
treat your specific case in its specific manner.  If you want your memory
initialized, then initialize it.

If the language cannot descriminate between your useful initialization
scenario and one that is detrimental in another case, then the language
has to take the least common denominator.

    Thomas Smith
    Elan Computer Group, Inc.
    (415) 964-2200
    tom@elan.com, ...!{ames, uunet, hplabs}!elan!tom