Re: [boost] boost::mpl::for_each and value_initialized

Subject: Re: [boost] boost::mpl::for_each and value_initialized
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2010-02-07 15:21:18

"Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote in message
news:op.uzp57jgyccf1k7_at_wonderland.office.meta...
> Hi Peter,
>
>> what is the use of value_initialized in boost::mpl::for_each?
>> It should be sufficient if the value is initialized by the constructor.
>
> In theory, yes. In practice, at the time when the code was authored,
> it wasn't -- see
> http://www.boost.org/doc/libs/1_40_0/libs/utility/value_init.htm

But why the insistence on _value_ initialization? Was it ever explicitly
demanded by someone?

Default initialization is, AFAIK, a perfectly standard C++ language construct
that, unlike value initialization, is not broken across compiler
implementations.

So:

>> value_initialized<arg> x;
>> aux::unwrap(f, 0)(boost::get(x));
- suffers from runtime and/or compile time performance issues (while providing
a certain 'defensive programming safe guard' for 'reckless programming'/not
knowing the difference between default and value initialization...but this IMO
should never take precedence over the 'you do not pay for what you do not use'
'directive'...'this' is not a 'managed' C#/Java environment after all...)

>> aux::unwrap(f, 0)(arg());
- suffers from 'possible undefined behaviour' and the 'sequence of array types'
and l/r-value issues

>> arg x;
>> aux::unwrap(f, 0)(x);
- suffers from none of the above...only the mpl::for_each documentation must be
changed to explicitly state that the objects passed are default, not value,
initialized...and when the value_initialized<> wrapper along with the
boost::get() call are eliminated the compiler will have a much better chance of
detecting that the passed object is actually not used (and then removing it all
together)...

Furthermore why to even pass default constructed objects? Why would the
desire/need to iterate over a sequence of types ever imply that one also wants
instances of default constructed objects of those types? If the only argument
is the support for plain function objects that can also be achieved with typed
null pointers.

Or...maybe all of this can be made a matter of policy...

-- 
 "That men do not learn very much from the lessons of history is the most
important of all the lessons of history."
 Aldous Huxley