Subject: Re: [boost] [range] [extensions] Default values for range access adaptors?
From: Viktor Sehr (viktor.sehr_at_[hidden])
Date: 2013-06-05 11:02:23
I totally agree, returning a boost::optional is a better solution than what
I proposed. Is there any way around this right now, or does the range
accessors require a non-empty range not to result in undefined
I'm very much looking forward to having range extensions included in boost.
On Wed, Jun 5, 2013 at 3:09 PM, Akira Takahashi <faithandbrave_at_[hidden]>wrote:
> Hi Viktor,
> 2013/6/5 Viktor Sehr <viktor.sehr_at_[hidden]>
> > I'd like to suggest the addition of a default value to the range access
> > adaptors. Either by adding it as an extra, non-necessary parameter for
> > functions, or by duplicating the functions as "front_or_default(T default
> > value)".
> > For example it would be useful for finding objects which I am not sure
> > exists in a range.
> > std::vector<int> vec = boost::assign::list_of(2)(4)(6);
> > auto first_odd = vec | filtered(is_odd) | front(); // undefined?
> > auto first_odd = vec | filtered(is_odd) | front_or_default(-1); //
> > everything is fine!
> > Another option would be a function which returns the adress, or nullptr
> > the value does not exist?
> > /Viktor
> My Boost.Range Extension has `front` accessor.
> This is now proposing to Boost.Range.
> However, I don't have `front_or_default` feature.
> I think better way is add `optional_front` feature (return
> boost::optional<T&>). Because `front` return `T&` but default value is not
> Akira Takahashi
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk