Path: utzoo!news-server.csri.toronto.edu!rpi!usc!apple!netcom!sjsumcs!horstman
From: horstman@mathcs.sjsu.edu (Cay Horstmann)
Newsgroups: comp.lang.c++
Subject: Re: Why no renew
Message-ID: <1991Mar16.172814.6525@mathcs.sjsu.edu>
Date: 16 Mar 91 17:28:14 GMT
References: <281@nazgul.UUCP> <1991Mar14.042611.14921@mathcs.sjsu.edu> <184@heurikon.heurikon.com>
Organization: San Jose State University - Math/CS Dept.
Lines: 83

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?
>
>	2) Any values needing initialization can be initialized
>	   by the constructor for the object.

I was talking about new applied to NON-CLASS TYPES. They don't have
a constructor.
>	   
>	3) Frequently the overhead for the constructor performing
>	   the initialization is little more than that required for
>	   initialization at allocation time.
>	

Ditto.
>	4) If initialization needs to be done field by field then extra
>	   code is added to the constructor to perform that initialization.
>	   This would be code which is often not needed.
>
>	5) Initialization of objects at allocation time adds time to
>	   the allocation of *every* object when it is needed for
>	   only a few objects.
>
>	6) For large objects such as buffers in the megabyte range
>	   initialization time can result in visible delays while
>	   buffers are allocated. For such buffers initialization
>	   is usually not needed.

Back here on planet Earth: operator new DOES CALL THE CONSTRUCTOR for
every array element when allocating an array of objects.  In C++ Ver. 2.0,
it was not possible to call operator new on a class that didn't have a
constructor with no arguments. I believe this has been relaxed in 2.1 --
a constructor with default arguments is called.

>
>	7) In addition to global operator new an objects operator new can
>	   be overloaded to initialize the memory if needed
>

Yes and no. (Mostly no.) Both for non-class types and for ARRAYS OF CLASS 
TYPES, the global ::operator new is called. While it can be changed, that is
not a good idea (ARM p.60) as a general purpose strategy.

>In summary it is my opinion (not that my opinion counts) that initialization
>of object upon allocation is of dubious benefit, and so is a waste of time
>and possibly code. I would prefer to see the spec remain the same. ANSI, are
>you listening?
>--
I mostly care about arrays here. (I rarely do a char* p = new char;) Arrays
of OBJECTS are initialized through a default constructor. You might get ANSI
to rescind that, but I doubt it. My suggestion is to have the same safety
when allocating arrays of non-class type. It is just fine with me if 
the initialization is restricted to arrays only, i.e. int* a=new int[100]
zeroes them out, but int* a = new int; doesn't. It would allow the efficiency
fanatics to get that single int allocated with stupendous speed. 

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. But
I got more HATE MAIL about it than about the lvalue/rvalue operator[]
stuff which, if adopted, would actually break code. 

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)*... ). 

Cay