🚀 go-pugleaf

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