Subject: Re: [boost] boost::mpl::for_each and value_initialized
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2009-10-01 09:12:54
"Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote in message
> Yep. I provided an example in the message you are referring to
i'm sorry, missed it somehow...
> typedef mpl::range_c<int,0,10> numbers;
> std::vector<int> v;
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk