Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!vsi1!octopus!sjsumcs!horstman From: horstman@sjsumcs.sjsu.edu (Cay Horstmann) Newsgroups: comp.lang.c++ Subject: Re: Overloaded operator new Message-ID: <1990Dec5.155604.24463@sjsumcs.sjsu.edu> Date: 5 Dec 90 15:56:04 GMT References: <1990Dec4.062015.6637@sjsumcs.sjsu.edu> Reply-To: horstman@sjsumcs.SJSU.EDU (Cay Horstmann) Organization: San Jose State University Lines: 67 In article cline@sun.soe.clarkson.edu (Marshall Cline) writes: (in response to my query why (a) there is the very general scheme of overloading operator new( size_t, any other parameters ) and (b) the corresponding delete syntax is not symmetric. > >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*'. > Yep, this is all very true. Indeed, operator new could place information into a "header" area of the block which an overloaded operator delete could find (by subtracting the header size from this...) My student was working on the idea of implementing several pools of memory, and she passed the address of a pool descriptor into new. So there is a possible use, I guess. I do realize that placement is useful. IF one agrees that new(p) X(...) is a good syntax for placement, then it is indeed reasonable to implement the more general new(...) X(...). Personally, I don't think this is very elegant. I would much favor the symmetric syntax p->X(...) to run X::X(...) on the preallocated p and p->~X(...) on the destructor, and separately deal with the allocation and deallocation of p. Orthogonality of language features. (You know, like in Algol 68 :-)) I do realize that it is against the spirit of constructors to run them on preallocated memory (but so is an explicit call to a destructor), and there- fore a yucky syntax may discourage some from doing so. Don't bet on it, though. You'll begin to see plenty "new(this) X() // clear the state " in student's code, I bet. Has anyone used the flexibility of operator new( size_t, ... ) for anything BUT placement? Cay Brought to you by Super Global Mega Corp .com