From: Martin Bonner (martin.bonner_at_[hidden])
Date: 2005-04-26 03:09:12
From: Pavel Chikulaev [mailto:pavel.chikulaev_at_[hidden]]
Sent: 25 April 2005 16:36
Subject: [boost] SmartPtrs: Making Code Self-Describing. Do we need
> Please consider the following code which we IMO too often see in other
> class Foo;
> Foo * Bar(Foo *);
> What can we say about this pretty C-like function? It gets pointer
> Foo and returns pointer Foo. That's all we can be sure about it.
> But that's not enough to start working with it. But without looking at
> documentation we can't say whether we should delete these pointers
> or function Bar will handle it. What if even documentation says
> anything about it, what to do then?
Discuss the lack of documentation with the original developer. (A 2x4 may
... You can't use a function if you don't know what it does. The
documentation might as well discuss lifetimes.
> Example 1:
> We are the developer of function Foo. And we need to mark somehow
> that returned pointer is property of Foo internals and it shouldn't be
> deleted by the client function. We can achieve this using weak_ptr, but
> what if Foo internals doesn't have any shared_ptr's ? What to return then?
What's wrong with returning a reference here?
> Example 2:
> We are developer of function Foo again. And now we need to mark that
> pointer argument is needed only for time of execution of Foo (it
> wasn't collected anywhere), and user cares about deallocation. How
> are we going to write such code and make it self-describing at the same
> time? Plain pointer? No Way! That would be a C-style, but we need
> something like C++-style... This time we don't have even one std or
> boost candidate for such job.
> Do we need them?
I don't think so.
> Or we've already have some alternative solution I didn't find?
I think so.
-- Martin Bonner Martin.Bonner_at_[hidden] Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk