Article View: comp.std.c++
Article #2006Re: placement delete
From: J. Kanze
Date: Fri, 22 Sep 1995 17:09
Date: Fri, 22 Sep 1995 17:09
59 lines
2583 bytes
2583 bytes
kanze (kanze@lts.sel.alcatel.de) wrote:
|> The other case is managing different pools of memory, perhaps using
|> different strategies. In this case, as far as I can see, the user
|> must also provide a non-placement form for new and delete; the normal
|> forms will *not* work. It is up to the delete to somehow figure out
|> which strategy to use to free the memory, given only its address.
Since posting the above, an idea on how to solve this using mixins has
occurred to me.
Consider the following:
class Pool1
{
public :
void* operator new( size_t ) ;
void operator delete( void* ) ;
virtual ~Pool1() {}
} ;
// Other pools the same.
class Buffer { /* ... */ } ;
class BufferInPool1 : public Buffer
, public Pool1
{
// Eventually, constructors, since they are not inherited
} ;
Buffer* p1 = new Buffer ;
Buffer* p2 = new BufferInPool1 ;
// ...
delete p1 ; // should use global delete
delete p2 ; // uses delete for Pool1
I believe that the above is legal, and will work as expected if Buffer
has a virtual destructor. It also offers a portable solution to
determining which pool is used in the destructor, and allows defining
operator new for specific pools without also having to define the normal
operator new.
The only problem I see is that I suspect that the most frequent use of
distinct pools is shared memory, and in general, virtual functions don't
work in shared memory:-(. (Since this is comp.STD.c++, however, and the
standard says nothing about shared memory, we can ignore this problem
here:-).)
--
James Kanze (+33) 88 14 49 00 email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
--Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
Technical Details
Message-ID:
<MATT.95Sep22100942@physics11.Berkeley.EDU>Path:
arc1-ca.pugleaf.net!128.32.155.1!mattReferences:
<MATT.95Sep18143159@physics10.Berkeley.EDU> <9509191009.AA17054@slsvhdt.lts.sel.alcatel.de>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!128.32.155.1!matt From: kanze@gabi-soft.fr (J. Kanze) Newsgroups: comp.std.c++ Subject: Re: placement delete Date: 22 Sep 1995 17:09:42 GMT Organization: GABI Software, Sarl. Approved: matt@physics11.Berkeley.EDU (Matt Austern) Message-ID: <MATT.95Sep22100942@physics11.Berkeley.EDU> References: <MATT.95Sep18143159@physics10.Berkeley.EDU> <9509191009.AA17054@slsvhdt.lts.sel.alcatel.de> NNTP-Posting-Host: physics11.berkeley.edu