🚀 go-pugleaf

jeffp@itsnet.com (Jeff Petersen) writes:
	...
>old discussions.  I have found in using third party class libraries that it is 
>often very difficult to determine who is responsible (the owner) for a 
>dynamically allocated object (or buffer or whatever) that is passed/returned 

Unfortunately true:-(.

>from a function.  I developed a convention that goes a little like this:
	...
>The 'gift' keyword tells the caller that the ownership of the dynamically 
>allocated object is being transferred and that they are responsible for 
>transferring it to someone else or deleteing it.

>I was wondering if something like this had been proposed and what the status 

Xerox's ILU orb uses a similarly defined-to-empty pseudo-keyword
RETAINS for the case where a pointer is passed (function argument or
return value) in what is NOT meant as a transfer of ownership (the
default being that such pointer-passing transfers ownership -- a
debatable matter of style, but, after all, *references* can be used in
many cases where no ownership transfer is meant).

If I were to use such conventions I would surely insist on a clear
separation between ownership-transferring pointers to SINGLE objects,
versus ones to ARRAYS of objects -- after all, the distinction
between delete and delete[] is just too crucial.

The standard's solution to this issue is more powerful than just a
conventional comment -- look up auto_ptr<T>... it *enforces* transfer
of ownership, as well as proper destruction when the owning-autoptr
goes out of scope (works for single objects only; we do need a version
of it for arrays too, of course, but I suspect the committee was
perhaps keen to discourage the use of builtin arrays in favour of STL
containers).  (There seem to be some technical problems with that in
terms of functions _returning_ an auto_ptr, but I trust/hope that some
fix for them will be found...).


>The only problem I have ran into is dealing with passing built-in types as 
>gifts (as in the first example above).  The problem is that if a library uses 
>it's own memory manager, the only way for the object to be properly freed is 
>for the new/delete operators to be globally overloaded and pointed at the 
>libraries memory manager.  A language feature that would be nice is if the 
>'delete' operator corresponding to the 'new' operator used to allocate a 
>built-in type would be guaranteed to be called regardless of where it was 
>being called from.

I think the overhead (basically, _every_ new'ed memory area would have
to include space for a pointer to the delete operation to call) might
be considered a bit high, particularly for built-ins, since they may
often be small.  Perhaps it's more feasible for new[]...


Alex
--
DISCLAIMER: these are TOTALLY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: martelli@cadlab.it                            Phone: +39 (51) 597313
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: +39 (51) 597120

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