Re: [boost] [range] [extensions] Default values for range access adaptors?

Hi, 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 behavior\crash? I'm very much looking forward to having range extensions included in boost. /Viktor On Wed, Jun 5, 2013 at 3:09 PM, Akira Takahashi wrote:

Hi Viktor,

2013/6/5 Viktor Sehr

...

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 the 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 if the value does not exist?

/Viktor

My Boost.Range Extension has `front` accessor.

http://dl.dropboxusercontent.com/u/1682460/git/OvenToBoost/libs/range/doc/ht... https://github.com/faithandbrave/OvenToBoost/tree/master/boost/range/access

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). Because `front` return `T&` but default value is not reference.

Thanks, Akira

...

...

======================== Akira Takahashi mailto:faithandbrave@gmail.com https://sites.google.com/site/faithandbrave/about/en

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost