🚀 go-pugleaf

In article <1991Mar31.164628.14033@mathcs.sjsu.edu> horstman@mathcs.sjsu.edu (Cay Horstmann) writes:
>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
>>own memory allocation (or reference count, or debug tracing, or whatever).
>
>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,....

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

>Cay

This is not the natural way of doing that. 
That is a poor way of doing it because it makes allocation of an
array indistinguishable from allocation of a scalar with an extra argument
to new of type size_t. 

A somewhat more natural way is to use another operator, e.g., ``vec_new'', 
for allocation of arrays.
The operator could take two arguments, a size_t and an unsigned.
However, I haven't considered the ramifications of this for
multidimensional arrays.

You almost need to support variable arguments. One tells the number
of dimensions and the others are the sizes in each dimension.

Perhaps ``vec_new()'' should take:

	void * T::vec_new(size_t obj_size, int ndims, unsigned sizes[])
	{
		...
	}

Where ndims is the number of dimensions in the array and sizes
is an array of the size in each dimension.

Hmm.

daniel