Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!apple!netcom!sjsumcs!horstman
From: horstman@mathcs.sjsu.edu (Cay Horstmann)
Newsgroups: comp.std.c++
Subject: Re: X3j16 "contractions"
Message-ID: <1991Mar31.164628.14033@mathcs.sjsu.edu>
Date: 31 Mar 91 16:46:28 GMT
References: <1991Mar30.065943.3074@lia>
Organization: San Jose State University - Math/CS Dept.
Lines: 31

In article <1991Mar30.065943.3074@lia> jgro@lia.com (Jeremy Grodberg) writes:
>I'd like to add to the list of contractions the "feature" that a class'
>overloaded operator new is not called when allocating an array of
>class objects.  This "feature" eliminates any clean way of handling, or
>prohibiting, arrays of classes in situations where you want to do your
>own memory allocation (or reference count, or debug tracing, or whatever).
>
I wouldn't call this a contraction of the language, but...

It would indeed be desirable if the class user could also control allocation
of arrays (or defer to ::operator new if the allocator isn't prepared to
handle arrays, e.g. if the allocator doles out fixed-size blocks in lifo
fashion). 

The natural way of doing that is to tinker with operator new and have the
compiler call X::operator new( size_t, size_t, ... ) when an array of X's
is allocated. 

This has the odd effect that calls 
	X* px = new X[n];
and
	X* px = new(n) X;
have the same result. But that is probably ok.

I realize that RIGHT NOW one could tell one's class users to allocate
arrays of X's using the second statement. But "telling the class user"
isn't usually great programming strategy. In particular, it isn't invariant
under change of allocation scheme ("since I just changed the allocation of
X's, please change all new X[n] to new(n) X").

Cay