Boost logo

Boost :

Subject: Re: [boost] std::map::find() wrapper
From: Robert Jones (robertgbjones_at_[hidden])
Date: 2011-05-04 08:28:05


On Wed, May 4, 2011 at 12:04 PM, Olaf van der Spek <ml_at_[hidden]> wrote:

> On Wed, May 4, 2011 at 12:50 PM, Robert Jones <robertgbjones_at_[hidden]>
> wrote:
> > On Wed, May 4, 2011 at 11:33 AM, Olaf van der Spek <ml_at_[hidden]>
> wrote:
> >
> >> On Wed, May 4, 2011 at 9:37 AM, Robert Jones <robertgbjones_at_[hidden]>
> >> wrote:
> >> > On Tue, May 3, 2011 at 8:52 PM, Olaf van der Spek <ml_at_[hidden]>
> wrote:
> >> >
> >> >> On Tue, May 3, 2011 at 6:57 PM, Robert Jones <
> robertgbjones_at_[hidden]>
> >> >> wrote:
> >> >> > I'd prefer to see it return a boost::optional<T&>
> >> >>
> >> >> What's the benefit?
> >> >>
> >> >
> >> > Simply that the difficulty you're addressing is the possibility that
> >> there's
> >> > no
> >> > value to return. Boost.optional expresses that directly.
> >>
> >> Returning NULL works just as well.
> >> Using a raw pointer also allows you to write string* ptr = find_ptr().
> >> Using Boost Optional would make that longer.
> >>
> >>
> > You'd have to write optional<string> s = find_ptr(); //Now misnamed of
> > course!
>
> boost::optional
> Shouldn't it be string&?
>

Indeed it should.

>
> > Either way, at some point you'd have to check the value was usable before
> > using it.
>
> Sure, but that can be done just as well with a pointer.
>

It can, optional is a generalisation of the no-value value offered by a
possibly null pointer.
The question is whether it should.

> Boost Optional is targeted at functions that return by value.
>

Is it? I'd always rather thought it targeted at functions that may not
necessarily return a value at all.

>
> What's the best way to get this wrapper into Boost?
>

In detail I don't know. I'm pretty sure you need SVN write access at some
point, unless someone
applies a patch for you. If it's more than a patch I guess review of your
code is required too.

- Rob.


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