🚀 go-pugleaf

In article <1990Aug19.170256.21630@athena.mit.edu> drk@athena.mit.edu (David R Kohr) writes:
>
>But in C++, the new and delete operators seem to have lost this
>capability of calculating the size of allocated memory regions
>automatically.

This is actually a pretty darn good question.

Back in the good 'ol days, if you new'ed up an array of twenty objects of
type T (where the type T required some destruction, either from a user-
supplied (explicit) destructor or from a compiler-supplied (implicit)
destructor) then when you wanted to delete that array, you had to say:

	delete [20] p;

so that the compiler would know that the destructor (either explicit or
implicit) should be called twenty times, i.e. once for each member of
the array of T's.

Well, we don't have to do that anymore.  Nowadays were supposed to be able
to expect the compiler and run-time system to do something intelligent
like sticking in a length (or count) word at the start of the space
allocated, so that later on we can just say:

	delete [] p;

and have the run-time system figure out 20 destructor calls are needed.

So why can't we just assume that there will always be such a length
word near the start of all memory areas allocated via new, and then further
assume that:

	delete p;

will always look for such a word and then destruct the proper number of things.
In other words, what do we need the (seemingly redundant) [] for?

Well, there's a case to be made that the [] is not redundant.  It's my
assumption (although I'm not at all sure about this) that the current
language definition tries to allow the implementation to save space by
avoiding the additon of a length word when we just allocate a simple
(non-array) object as in:

		T* tp = new T;

if my supposition is correct, then this explains why we need to have two
different forms of delete operator because the `tp' pointer could (as far
as the compiler is concerned) point either to a single T (with no length
word) or to an array of T's (with a length word).  Thus, the two different
forms of delete instruct the compiler to call one of two possible (radically
different) forms of run-time delete routines.

So that's that.

While we are on the subject however, I'd like to reraise one point that I
raised some time back in comp.lang.c++.  The point is that if new and
delete understood more about types, and if they were more `type correct'
then we could get by with only one form of delete.

In particular, the thing that bothered me (and still bothers me) about the
current C++ language definition with respect to new and delete is that
new seems to be `type incorrect' in the case of allocating arrays.

For example, given the expression:

	new T

where T is some type, what is the type of the value yielded?  Answer: you
can't tell.  For any "normal" type, the type of the value yielded is (of
course) `T*' however if T were defined as:

	typedef some_other_type T[10];

Then the type of the value yielded is type `some_other_type*'.

Most of the folks I have discussed this inconsistancy with see it as `no
big deal' however I'd like to see there be a more consistant rule which
says that `new T' yields a `T*' regardless of the nature of type T.

If such a rule were adopted, then we would need only one form of delete
statement.  Given:

	delete p;

the compiler could easily decide which run-time delete routine to call based
strictly upon the static type of `p'.  If p's type were some pointer-to-non-
array type, then the simple delete routine would be called.  If however the
type of `p' were some pointer-to-array type, then the array-delete run-time
routine would be called.

I believe that getting new to act in a more `type correct' manner would
have other benefits also.  I'll probably try to enumerate those in a
separate posting.

Anyway, am I the only one on the planet who thinks that this is even
worth discussing?  If so, I'll shutup (about this anyway :-).
-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.