Boost logo

Boost :

Subject: Re: [boost] std::map::find() wrapper
From: Olaf van der Spek (ml_at_[hidden])
Date: 2011-05-04 14:15:06


On Wed, May 4, 2011 at 3:08 PM, Stewart, Robert <Robert.Stewart_at_[hidden]> wrote:
> Olaf van der Spek wrote:
>> On Wed, May 4, 2011 at 2:37 PM, Rob Riggs <rob_at_[hidden]>
>> wrote:
>>
>> > One of the hallmarks of modern C++ programming is the absence
>> > of bare pointers.  We have iterators, smart pointers and
>> > pointer containers to manage and hide pointers for us.  We
>> > have a healthy distrust of bare pointers because they are so
>> > easily misused.
>>
>> I'm not sure what your code looks like, but IMO bare pointers
>> are perfectly fine in certain situations.
>> Like this one, where no ownership issues are present.
>
> A function that returns a pointer immediately begs the question of ownership.  It is perfectly reasonable to think that one should call delete on such a pointer when finished with it.  That, of course, would have nasty consequences, but it is the result of returning a pointer.

Is it? I've no idea why that would be reasonable. You don't delete
something just because you can.

> Returning a boost::optional with a reference to the element conveys two things.  First, the reference clearly indicates that the container maintains ownership.  Second, there may be no value.  Whether the limitations of optional when using reference types is a problem in this context, I'll leave to you (see <http://www.boost.org/doc/libs/1_46_1/libs/optional/doc/html/boost_optional/optional_references.html>).

Providing a variant that returns boost::optional (find_opt /
find_optional) is of course possible.

> Local conventions may dictate that all ownership transfers are done via std::auto_ptr, for example, and never through raw pointers, leaving raw pointers as non-owning, possibly null references.  Boost, however, is used in various places with different conventions.

You can't expect every single lib to follow your local convention, can you?

Olaf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk