----Original Message---- From: Pavel Chikulaev [mailto:pavel.chikulaev@gmail.com] Sent: 25 April 2005 16:36 To: boost@lists.boost.org Subject: [boost] SmartPtrs: Making Code Self-Describing. Do we need more SmartPtrs?

Please consider the following code which we IMO too often see in other libraries: 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 be useful). ... 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. Reference definitely.

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@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434