Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: new/dispose behavior
Message-ID: <72369@microsoft.UUCP>
Date: 15 May 91 17:49:01 GMT
References: <1619@msa3b.UUCP> <2210002@hpfelg.HP.COM>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 62

In article <2210002@hpfelg.HP.COM> greg@hpfelg.HP.COM (Greg Begay) writes:
|>True or False: If one wants to delete all of the 'new-ed' storage one need
|>               not specify the quantity to delete, just the pointer to the
|>               storage.
|>-- 
|
|True if the pointer is to storage containing homogenious data (ie, one type
|of data).  What if you want to free the storage of an array of objects?
|How will the compiler know to call the destructors (and how many
|destructors to call) for the objects in the array?

I disagree -- in theory.  ARM page 64 calls for programmers to use:

delete [] ptrthingee

where ptrthingee is some kind of an expression referring to some kind
of array allocated via new.

and programmers to use:

delete ptrthingee

where ptrthingee is some kind of an expression referring to some kind of
individual item allocated via new.

However, in practice, C++ compiler implementations today vary so widely
in what they expect that all one can do is experiment and try to discover
the behavior of one's compiler.  Many implementations are "busted" in one way
or another, so be prepared for the unexpected.

The language could have been designed such that the allocation routines
were required to keep track of how many objects [1 to N] are being
allocated, what size and types those objects are, etc, but this was
considered to be too much overhead.  By requiring programmers to specify
the [] when deleting arrays, implementors are given the option of using
separate allocation schemes for arrays vs individual objects -- with the
remembering number of elements allocated [and hence needing to be 
destroyed] only required for array allocations.  Also, implementations
might want to specialize their allocation schemes under the assumption
that individual object allocations are typically quite small, whereas
array allocations can be quite big.

Unfortunately, all this comes down to inherent problems with the 
multiple overloaded meanings of a "pointer" in C/C++:

1) a reference to an individual object or
2) a reference to an array or
3) a reference to a start of an array or
4) a reference to an element in an array or
5) a reference to whatever would be one past the end of an array if such
	object actually existed or
6) a byte address of what programmers typically mistakenly refer to as
	physical memory but which is actually, usually, a reference to a
	virtual address of a relocatable group of bytes, said fact
	cleverly hidden from some programmers in some simple situations
	via a complicated system of software/firmware/hardware, and 
	not hidden at all from programmers in more complicated situations,
	such as those doing "object oriented programming."

This situation could have been somewhat repaired had C++ provided enough
power to C++ "references" that they could have been commonly used instead
of pointers.  But, this is presumably water under the bridge.