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

jeffp@itsnet.com (Jeff Petersen) wrote:
>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 
>from a function.  

    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 developed a convention that goes a little like this:
>#define gift
>gift char *GetString();
>
>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 
>of it was.  Although this can be implemented without changing the standard (as
 
>shown above), it would be nice if everybody would follow the convention.  Most
 
>libraries I use end up fudging around the problem and avoiding passing gifts 
>around at the cost of code clarity.

I do NOT believe it appropriate to standardise an ad hoc
protocol -- there are many other idioms. The solution is
for library suppliers to provide the adequate documentation.

[Example of another protocol -- Andrew Koenig's cluster
controller has an object to which allocated objects
are attached, they're all deleted automatically when the
controller object is destroyed. In MY implementation,
they can be destroyed prematurely as well, but not
in Andrew's.

Note the issue is more than "when/if do I delete this object?"
The issue is also "when can I use the pointer?" and that INCLUDES
copying objects containing the pointer. It's important to
0 out data members of copyable objects which are pointers to
delete objects -- or document when such objects are not
copyable]

Hopefully the C++ Standard Library will provide a good
example of how to do good documentation of component
libraries and people will follow the model.

-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au
---
[ 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. ]

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