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

In article <46m7ap$e30@oznet03.ozemail.com.au> John Max Skaller <maxtal@suphys.physics.su.oz.au> writes:

>     I agree and I consider the single WORST problem of
> class libraries -- failure to correctly document
> responsibilities. Some library developers would do well
> to read Meyer or other works describing the contracting
> paradigm.

I agree that most libraries I've seen fail to document responsibility
adequately, but I'm not sure that "programming by contract" would
really help all that much in the case at hand---that is, documentating
who owns some object and when and how it is to be deleted.  If, for
example, some member function in a library returns a pointer that is
supposed to be deleted by the client, I don't see how this requirement
can be expressed as a precondition or a postcondition.

Careful documentation can help somewhat; so can using appropriate
protocols.  The most obvious one is auto_ptr, assuming that there's a
decent solution to the problem of returning an auto_ptr from a
function.  Sometimes an auto_ptr might not be adequate, and it will
necessary to use reference-counted pointers.

And while I'm on the subject of reference counted pointers...  Does
anyone know why an rc_ptr<X>, something analogous to auto_ptr<X>,
isn't in the standard class library?  It's possible to write an rc_ptr
class that's only a little bit more complicated than auto_ptr.
--
  Matt Austern                             He showed his lower teeth.  "We
  matt@physics.berkeley.edu                all have flaws," he said, "and
  http://dogbert.lbl.gov/~matt             mine is being wicked."


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

"Taligent's Guide to Designing Programs" (Addison Wesley, 1994) has
some things to say about this.  Taligent recommends a naming convention
for C++ functions that can be summarized as follows:

Create... for functions that make a new object that the caller must
  delete.

Copy... for functions that copy an existing object that the caller
  must delete.

Orphan... for functions that pass deletion responsibility to the caller.

Adopt... for functions that assume responsibility for deleting objects
  that have been allocated by the caller.

This convention can be extended for argument names; e.g., a constructor
for an objects that takes on ownership of the arguments:

  AndNode::AndNode(Node* adoptedLeftChild, Node* adoptedRightChild)

IMHO, object ownership is not a big deal if you conciously design for it,
and use conventions like those above to help document the decisions.
---
[ 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 <MATT.95Oct26011259@godzilla.EECS.Berkeley.EDU> matt@physics.berkeley.edu writes:

...
>
>And while I'm on the subject of reference counted pointers...  Does
>anyone know why an rc_ptr<X>, something analogous to auto_ptr<X>,
>isn't in the standard class library?  It's possible to write an rc_ptr
>class that's only a little bit more complicated than auto_ptr.

The standard has no reference counted pointer class because I and others
failed to convince the committee that it should, despite about two years
of effort. Personally, I prefer garbage collection to reference counting,
and reference counting to strict ownership, but strict ownership is the
most we could agree on for the standard, and even that agreement was hard
to arrive at.

Greg Colvin
gregor@netcom.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. ]