[range] cannot use lambda predicate in adaptor with certain algorithms
Hello,
I get errors related to lambdas not being default-constructible or copy-assignable
when using a lambda as a predicate with certain adaptors (e.g. filtered) and
certain algorithms (e.g. min_element).
The following code illustrates the problem:
#include
Hi Nate, Nathan Ridge wrote:
I get errors related to lambdas not being default-constructible or copy-assignable when using a lambda as a predicate with certain adaptors (e.g. filtered) and certain algorithms (e.g. min_element).
The following code illustrates the problem:
#include
#include int main() { int a[] = {1, 2, 3}; auto is_odd = [](int i){ return i % 2 == 1; }; boost::min_element(a | boost::adaptors::filtered(is_odd)); } The errors are shown below.
Is there a workaround for this?
I don't have any workarounds :-( but I'd like to make a comment. I think filter_iterator and transform_iterator should use boost::optional to cope with this kind of problems. For transform_iterator, there's a trac ticket https://svn.boost.org/trac/boost/ticket/4189 Unfortunately there is no reaction on this ticket. Regards, Michel
Nathan Ridge wrote:
The following code illustrates the problem:
#include
#include int main() { int a[] = {1, 2, 3}; auto is_odd = [](int i){ return i % 2 == 1; }; boost::min_element(a | boost::adaptors::filtered(is_odd)); } The errors are shown below.
Is there a workaround for this?
Use oven::regular boost::min_element(a | boost::adaptors::filtered(pstade::oven::regular(is_odd)) ); and here is the documentation of oven::regular http://p-stade.sourceforge.net/oven/doc/html/oven/utilities.html#oven.utilit... *** Note *** `#define BOOST_RESULT_OF_USE_DECLTYPE` is necessary to compile the above code. Without this, we have compiler errors (the oven library seems not fully compatible with new compilers yet). Regards, Michel
Hi, Michel.
`#define BOOST_RESULT_OF_USE_DECLTYPE` is necessary to compile the above code. Without this, we have compiler errors (the oven library seems not fully compatible with new compilers yet).
I am Oven Library mantainer(now manager). I think implicit BOOST_RESULT_OF_USE_DECLTYPE support shoube Boost side. C++0x lambda hasn't result_type typedef, but BOOST_RESULT_OF_USE_DECLTYPE needs user side define. I think BOOST_RESULT_OF_USE_DECLTYPE is should auto define.
======================== Akira Takahashi mailto:faithandbrave@gmail.com blog:http://d.hatena.ne.jp/faith_and_brave/
Hi Akira, Akira Takahashi wrote:
Hi, Michel.
`#define BOOST_RESULT_OF_USE_DECLTYPE` is necessary to compile the above code. Without this, we have compiler errors (the oven library seems not fully compatible with new compilers yet).
I am Oven Library mantainer(now manager).
Good to know :)
C++0x lambda hasn't result_type typedef
Ah, this is the reason for the compiler error. Thanks for correcting me. (Cc'ing to Daniel) So, when using boost::result_of with C++0x lambda functions, we have to define BOOST_RESULT_OF_USE_DECLTYPE. This is a bit bothersome, and so I expect that, in the future, BOOST_RESULT_OF_USE_DECLTYPE gets automatically defined in compilers with N3276 support. Something like // boost/utility/result_of.hpp #ifndef #BOOST_NO_DECLTYPE_N3276 #define BOOST_RESULT_OF_USE_DECLTYPE #endif ? (BOOST_NO_DECLTYPE_N3276 is not yet included in Boost.Config.) Regards, Michel
On Mon, May 30, 2011 at 12:41 PM, Michel MORIN
Akira Takahashi wrote:
C++0x lambda hasn't result_type typedef
Ah, this is the reason for the compiler error. Thanks for correcting me.
(Cc'ing to Daniel) So, when using boost::result_of with C++0x lambda functions, we have to define BOOST_RESULT_OF_USE_DECLTYPE. This is a bit bothersome, and so I expect that, in the future, BOOST_RESULT_OF_USE_DECLTYPE gets automatically defined in compilers with N3276 support. Something like // boost/utility/result_of.hpp #ifndef #BOOST_NO_DECLTYPE_N3276 #define BOOST_RESULT_OF_USE_DECLTYPE #endif ? (BOOST_NO_DECLTYPE_N3276 is not yet included in Boost.Config.)
At some point, BOOST_RESULT_OF_USE_DECLTYPE may be defined by default,
probably when there's enough user interest, so thanks for cc'ing me.
The reason it is currently not defined by default is that it is
possible that it could introduce breaking changes to some C++03
function objects; e.g. if a function object defines result_type to be
some type other than the type of a call expression, then in C++03
result_of would give the user-specified result_type rather than the
actual result type, whereas in C++0x result_of always gives the actual
result type. For example:
#include
Thank you Michel and Akira! The regular() solution works well. Akira, do you have any plans to submit OvenToBoost for inclusion in Boost.Range? Thanks, Nate.
Akira, do you have any plans to submit OvenToBoost for inclusion in Boost.Range?
I am going to submit it if I finish writing a document. Quickbook & English is difficult...
======================== Akira Takahashi mailto:faithandbrave@gmail.com blog:http://d.hatena.ne.jp/faith_and_brave/
Hi, Nathan.
This problem is known issue.
PStade.Oven Library have solution by regular function.
http://p-stade.sourceforge.net/oven/doc/html/oven/utilities.html#oven.utilit...
I’ve been doing for now, Oven to Boost.Range porting project.
https://github.com/faithandbrave/OvenToBoost
Using this library you can write as follow:
#include
Hello,
I get errors related to lambdas not being default-constructible or copy-assignable when using a lambda as a predicate with certain adaptors (e.g. filtered) and certain algorithms (e.g. min_element).
The following code illustrates the problem:
#include
#include int main() { int a[] = {1, 2, 3}; auto is_odd = [](int i){ return i % 2 == 1; }; boost::min_element(a | boost::adaptors::filtered(is_odd)); } The errors are shown below.
Is there a workaround for this?
Thanks, Nate.
======================== Akira Takahashi mailto : faithandbrave@gmail.com blog : http://d.hatena.ne.jp/faith_and_brave/
participants (4)
-
Akira Takahashi -
Daniel Walker -
Michel MORIN -
Nathan Ridge