Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!clarkson!grape.ecs.clarkson.edu!cline
From: cline@cheetah.ece.clarkson.edu (Marshall Cline)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded operator new
Message-ID: <CLINE.90Dec4111352@cheetah.ece.clarkson.edu>
Date: 4 Dec 90 17:13:52 GMT
References: <1990Dec4.062015.6637@sjsumcs.sjsu.edu>
Sender: @grape.ecs.clarkson.edu
Reply-To: cline@sun.soe.clarkson.edu (Marshall Cline)
Organization: (I don't speak for the) ECE Dept, Clarkson Univ, Potsdam, NY
Lines: 64
In-Reply-To: horstman@sjsumcs.sjsu.edu's message of 4 Dec 90 06:20:15 GMT

In article <1990Dec4.062015.6637@sjsumcs.sjsu.edu> horstman@sjsumcs.sjsu.edu (Cay Horstmann) writes:
>One of my students just had the bright idea to abuse the placement syntax
>of the new operator 
>  new (p) X(...);
>to overload X::operator new( size_t, void* ) and feed something entirely
>different into p than the "placement address". 
>I told her that was a subversive idea, but then I looked into the ARM and
>saw that it is possible to overload X::operator new( size_t, int) and make
>a call new(7) X(...). 
>Is this stuff actually useful?
>I guess someone must have thought it is. I grant that the placement operation
>has its use, but I was always mystified by its syntax. I mean, if you call the
>destructor explicitly with 
>  p->~X(),
>why not call the constructor explicitly with
>  p->X(...)
>instead of 
>  new(p) X(...)
>(provided nobody tinkered with the definition of X::operator new().)
>Any info (preferably by e-mail; I'll summarize if there is interest) would
>be greatly appreciated. Hate mail too...
>Cay

Cay always has such colorful expressions (`abuse the placement syntax',
`subversive idea', etc)!!

As usual in C++, generality rules.  Ie: it seems more general to allow
                        new(size_t, any other parameters at all);
than to restrict it to  new(size_t, void*);

Ie: if I want to allow people to allocate objects of class X by some
pseudo-index, why not allow  ``new(size_t,int)''

Or if I want them to allocate X's from some pool of memory, why not
``new(size_t,Pool&)''

etc.

The problem with all this is that the *client* must remember where the
object came from, and delete has only one syntax.  The ARM (p.65-6)
discusses the possibility of having a matching placement deletion
syntax, but argues that it requires the client to remember all this
stuff, so that the client has to choose the right deletion routine.

Page 66 discusses an alternative which dispatches based on the actual
type of an `Arena' or `Pool' of memory.  Unfortunately this still
requires the client to remember whence an object cometh.

I suppose a sufficiently concerned supplier could overload operator
new so that it remembers the actual Arena/Pool.  A corresponding
operator delete would then use that Arena/Pool.  But an object isn't
`born' until its ctor builds it from the raw bits returned from `new',
and it dies during the dtor, which is before `delete' tries to peek at
the cached `Pool*'.

Any better solutions?
Marshall Cline
--
PS: If your company is interested in on-site C++/OOD training, drop me a line!
PPS: Career search in progress; ECE faculty; research oriented; will send vita.
--
Marshall Cline / Asst.Prof / ECE Dept / Clarkson Univ / Potsdam, NY 13676
cline@sun.soe.clarkson.edu / Bitnet:BH0W@CLUTX / uunet!clutx.clarkson.edu!bh0w
Voice: 315-268-3868 / Secretary: 315-268-6511 / FAX: 315-268-7600


Brought to you by Super Global Mega Corp .com