Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!uwm.edu!uwvax!heurikon!ex.heurikon.com!daves
From: daves@ex.heurikon.com (Dave Scidmore)
Newsgroups: comp.lang.c++
Subject: Re: Why no renew
Message-ID: <220@heurikon.heurikon.com>
Date: 22 Mar 91 01:56:25 GMT
References: <1991Mar16.172814.6525@mathcs.sjsu.edu> <966@elan.Elan.COM> <1991Mar21.163616.20136@mathcs.sjsu.edu>
Sender: news@heurikon.heurikon.com
Reply-To: daves@ex.heurikon.com (Dave Scidmore)
Organization: Heurikon Corporation, Madison, WI
Lines: 43

(Cay Horstmann) writes:
>It is much smarter to start out with a smaller array and grow it as needed
>with a variable array class. 

Not if the array could get very large as the copying of the old small array
to the new large array can get extreemely expensive.

>If you must allocate such a large array, and the penalty for zeroing it
>out is unacceptable, you can call malloc. 

And if the zeroing of the array is mandatory, you can simply clear it after
allocating it (which my original contention is won't be required often.)

>To inject a little more realism into the discussion: Most processors have
>instructions that can zero out a memory block extremely quickly. But if
>you have lots of large blocks of memory "just in case", your program is
>much more likely to have to page them out, which is a zillion times more
>expensive. 

Assuming it is not a imbeded processor or a dedicated application which does
not have a paging operating system to run under.

>I continue to propose that operator new zero out arrays of non-class type,
>and that programmers who find that unacceptable use malloc. 

One thing that occurred to me recently is that the proposal to zero memory
on array allocation of built in types is inconsistent with the way class
objects behave. Class objects can only call a constructor if one exists for
the class being arrayed. This is to ensure that an array of class objects
is initialized that same way an individual object of the same class would
be. Built in types are not cleared upon allocation and in that sense they
are similar to class objects with no constructor. Therefore an array of
built in types should not be cleared since this is exactly the opposite
of what happens when you only allocate a single built in type. The rules
regarding calling the constructor for arrays of class objects were designed
to provide arrays with class objects that are virtually identical to the
non array ones. Proposing that built in type be cleared when appearing in
an array but not individually does just the opposite. Requiring them to
be cleared in all cases is inconsistent with class objects which are not
cleared when no constructor exists.
--
Dave Scidmore, Heurikon Corp.
dave.scidmore@heurikon.com