🚀 go-pugleaf

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