🚀 go-pugleaf

rmartin@rcmcon.com (Robert Martin) writes:
> That thread also suggested that the only way to explicitly call placement
> delete would be to overtly call the appropriate operator delete.  e.g.
> 
> 	operator delete (object, arg1, arg2);

In fact, wouldn't you have to call `operator delete' with the address of the
most derived subclass object?  How would you do that?

> Now, as I understand it, such a call will not cause the destructor of the
> object to be called.  Thus, of one is to invoke the placement syntax of
> operator delete, one must first explicitly call the destructor.
---
[ 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. ]

In article <FENSTER.95Sep18204129@shadow.cs.columbia.edu>,
fenster@cs.columbia.edu (Sam Fenster) wrote:
> rmartin@rcmcon.com (Robert Martin) writes:
> > That thread also suggested that the only way to explicitly call placement
> > delete would be to overtly call the appropriate operator delete.  e.g.
> > 
> >       operator delete (object, arg1, arg2);
> 
> In fact, wouldn't you have to call `operator delete' with the address of the
> most derived subclass object?  How would you do that?

     operator delete (dynamic_cast<void*>(object), arg1, arg2);

-- 
Bill Gibbons
bgibbons@taligent.com


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

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