[range] [extensions] Default values for range access adaptors?

newer
Re: [boost] [multiprecision] Are...

older
boost.range bug in transformed or...

Viktor Sehr

5 Jun 2013 5 Jun '13

12:50 p.m.

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

Show replies by date

Akira Takahashi

5 Jun 5 Jun

1:09 p.m.

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

Viktor Sehr

3:02 p.m.

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

Michel Morin

3:09 p.m.

Akira Takahashi wrote:

...

My Boost.Range Extension has `front` accessor.

"Range Access" adaptors in your extensions are interesting. For the consistency of range adaptors, shouldn't `front` adaptor return `single` range? Regards, Michel

Viktor Sehr

3:16 p.m.

Michel: Why would you want a single range? (assuming a range of size one) /Viktor On Wed, Jun 5, 2013 at 5:09 PM, Michel Morin wrote:

...

Akira Takahashi wrote:

...
My Boost.Range Extension has `front` accessor.

"Range Access" adaptors in your extensions are interesting. For the consistency of range adaptors, shouldn't `front` adaptor return `single` range?

Regards, Michel

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

Michel Morin

3:30 p.m.

Hi Viktor, Please don't top-post ;) ( http://www.boost.org/community/policy.html ) Viktor Sehr wrote:

...

Michel: Why would you want a single range? (assuming a range of size one)

Just for the consistency: range adaptors return a range. But I also admit that this consistency might degrade the usability of "Range Access" adaptors. Regards, Michel

Akira Takahashi

6 Jun 6 Jun

4:35 a.m.

Hi Michel, 2013/6/6 Michel Morin

...

Akira Takahashi wrote:

...
My Boost.Range Extension has `front` accessor.

"Range Access" adaptors in your extensions are interesting. For the consistency of range adaptors, shouldn't `front` adaptor return `single` range?

I see. `optional_front` usage is following: if (optional<T> x = r | optional_front()) { std::cout << x.get() << std::endl; } If `front` return signle range, the usage is following: for (T x : x | front) { std::cout << x << std::endl; } If `front` is error, the return value is empty range. I think single range approach is better. However, I think now `front` and `optional_front` is useful. I would like to add `optional_front` and `front_range`. Thanks! Akira

Akira Takahashi

8:17 a.m.

2013/6/6 Akira Takahashi

...

Hi Michel, ... I see. `optional_front` usage is following:

if (optional<T> x = r | optional_front()) { std::cout << x.get() << std::endl; }

If `front` return signle range, the usage is following:

for (T x : x | front) { std::cout << x << std::endl; }

If `front` is error, the return value is empty range. I think single range approach is better. However, I think now `front` and `optional_front` is useful.

I would like to add `optional_front` and `front_range`.

I implemented `optional_front`, `optional_back`, and `optional_at`. https://github.com/faithandbrave/OvenToBoost/commit/3c828848be96de1c7d5d17a9... usage: #include <iostream> #include <vector> #include #include #include bool is_even(int x) { return x % 2 == 0; } int main() { using namespace boost::adaptors; using namespace boost::range::access; std::vector<int> v = boost::assign::list_of(1)(2)(3); if (boost::optional x = v | filtered(is_even) | optional_front) { std::cout << x.get() << std::endl; } else { std::cout << "not found" << std::endl; } } result: 2 Thanks, Akira

...

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

Viktor Sehr

1:10 p.m.

...

I implemented `optional_front`, `optional_back`, and `optional_at`.

https://github.com/faithandbrave/OvenToBoost/commit/3c828848be96de1c7d5d17a9... Great, I hope this all makes it into boost soon. /Viktor

Robert Jones

1:23 p.m.

On 6 June 2013 09:17, Akira Takahashi wrote:

...

I implemented `optional_front`, `optional_back`, and `optional_at`.

https://github.com/faithandbrave/OvenToBoost/commit/3c828848be96de1c7d5d17a9...

Why have you dropped 'BOOST_DEDUCED_TYPENAME' in favour of 'typename'? - Rob.

Akira Takahashi

1:54 p.m.

2013年6月6日木曜日 Robert Jones robertgbjones@gmail.com:

...

On 6 June 2013 09:17, Akira Takahashi javascript:;> wrote:

...
I implemented `optional_front`, `optional_back`, and `optional_at`.

https://github.com/faithandbrave/OvenToBoost/commit/3c828848be96de1c7d5d17a9...

...
Why have you dropped 'BOOST_DEDUCED_TYPENAME' in favour of 'typename'?

This macro is unneccesary for now Boost support platform. --

...

...
========================

高橋晶(Akira Takahashi) mailto:faithandbrave@gmail.com ブログ「Faith and Brave - C++で遊ぼう」 http://d.hatena.ne.jp/faith_and_brave/

Yusuke Ichinohe

7 Jun 7 Jun

7:41 p.m.

Hi Michel, Akira, I think simpler solution would be to add range support for boost::optional in additional header (e.g. ). i.e. boost::optional will become random access range. // OK #include for (T x : r | optional_front()) { std::cout << x << std::endl } // also OK if (optional<T> x = r | optional_front()) { std::cout << x.get() << std::endl; } // another example: #include optional<int> x = 100; assert(boost::size(x) == 1); optional<int> y = boost::none; assert(boost::size(y) == 0); Thanks. 2013/6/6 Akira Takahashi :

...

Hi Michel,

2013/6/6 Michel Morin

...
Akira Takahashi wrote:

...
My Boost.Range Extension has `front` accessor.

"Range Access" adaptors in your extensions are interesting. For the consistency of range adaptors, shouldn't `front` adaptor return `single` range?

I see. `optional_front` usage is following:

if (optional<T> x = r | optional_front()) { std::cout << x.get() << std::endl; }

If `front` return signle range, the usage is following:

for (T x : x | front) { std::cout << x << std::endl; }

If `front` is error, the return value is empty range. I think single range approach is better. However, I think now `front` and `optional_front` is useful.

I would like to add `optional_front` and `front_range`.

Thanks! Akira

-- ' Yusuke Ichinohe ' yusuke.ichinohe@gmail.com

Akira Takahashi

8 Jun 8 Jun

11:51 a.m.

Hi Yusuke, 2013/6/8 Yusuke Ichinohe

...

Hi Michel, Akira,

I think simpler solution would be to add range support for boost::optional in additional header (e.g. ). i.e. boost::optional will become random access range.

// OK #include for (T x : r | optional_front()) { std::cout << x << std::endl }

// also OK if (optional<T> x = r | optional_front()) { std::cout << x.get() << std::endl; }

// another example: #include optional<int> x = 100; assert(boost::size(x) == 1); optional<int> y = boost::none; assert(boost::size(y) == 0);

Thanks.

Thank you for your comment. That's good idea! I agree first design. But I think need more vote. Thanks, Akira

...

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

Michel Morin

9 Jun 9 Jun

12:28 p.m.

Yusuke Ichinohe wrote:

...

I think simpler solution would be to add range support for boost::optional in additional header (e.g. ). i.e. boost::optional will become random access range.

I saw this "container-view of boost::optional" on the Boost ML in the past, but I don't remember what was the conclusion. If you want to make this support added in Boost.Range, I recommend you to start a new thread (with the magic words "Oven range library already has this functionality"). And please don't top-post! ( http://www.boost.org/community/policy.html ) Regards, Michel

Michel Morin

12:26 p.m.

Akira Takahashi wrote:

...

If `front` return signle range, the usage is following:

for (T x : x | front) { std::cout << x << std::endl; }

If `front` is error, the return value is empty range.

This looks like `taken(1)`. Considering the fact that `container.front()` assumes `rng` is not empty, I came up with another idea: implementing `front` as a range-unchecking version of `taken` (`front(n)` requires that the range has length at least n), and `front` defaults to `front(1)`. (BTW, the documentation says that `taken` returns BidirectionalRange, but I believe `taken` returns ForwardRange.)

...

I think single range approach is better. However, I think now `front` and `optional_front` is useful.

I would like to add `optional_front` and `front_range`.

IMO, your `front` and `optional_front` are not range adaptors; they're range functions that use a pipe operator. Because they introduce a new syntax to Boost.Range, it would be better to make discussions about this syntax in a new thread. If this new syntax is accepted, then it is natural to expect that other range functions (size, all_of, etc.) are also supported. Regards, Michel

4189

Age (days ago)

4193

Last active (days ago)

List overview

Download

14 comments

5 participants

participants (5)

Akira Takahashi
Michel Morin
Robert Jones
Viktor Sehr
Yusuke Ichinohe