"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote in message news:op.uzp6h4quccf1k7@wonderland.office.meta...
Yep. I provided an example in the message you are referring to above:
i'm sorry, missed it somehow...
typedef mpl::range_c<int,0,10> numbers; std::vector<int> v; mpl::for_each<numbers,mpl::_>( boost::bind(push_back, &v, _1) );
true this does actually compile and work...but i still don't understand how :) because (as far as i understand) mpl::for_each feeds mpl::int_ objects not POD ints to the functor (created with bind) in the above case and the functor expects and accepts only POD ints (not mpl::int_s)...
and that "it's not portable" (the ::operator()<arg>() syntax is not standard?)...
Standard != portable in practice.
true but..hmm..we are talking mpl here :) i'd suspect that pretty much eliminates a lot of 'too' defficient compilers...perhaps a 'dual' approach can be taken like in boost::function where you have one 'proper' syntax and a 'backup'/different one for non-conformant compilers... the status quo design penalizes 'those with a 'good enough' compiler' in terms of verbosity (thus probably even sligthtly in terms of compilation time, if you do the sequence transformation step proposed by David Abrahams) and/or efficiency (unused object construction) because of those with a 'defficient' compiler...considering the freely available gcc and msvc++ (express) that are 'good enough' this decision does not seem justified imho (ofcourse if we do not take the argument of 'ordinary function objects' into account)... perhaps 'typed null pointers' could be passed..? anyway it would be usefull if the final design decision would make it to the official documentation with an explanation to prevent further resurrection of this topic ;) -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley