Boost logo

Boost :

Subject: Re: [boost] boost::mpl::for_each and value_initialized
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2010-02-08 15:51:22

"Domagoj Saric" <dsaritz_at_[hidden]> wrote in message
>>> aux::unwrap(f, 0)(arg());
> - suffers from 'possible undefined behaviour'

The above should have said "suffers from possible buggy/non-standard

>>> arg x;
>>> aux::unwrap(f, 0)(x);
> - suffers from none of the above...

The above should have said "does not suffer from buggy/non-standard behaviour
but from the problem of undefined behaviour inherent in default initialization"
which, IMO, is only an issue if you want to protect programmers that 'forget
the difference between default initialization and value initialization' (by
making 'managing' the issue for them, i.e. making everyone pay in
performance)... crossed my mind that writing the lines in question like this:

  aux::unwrap(f, 0)( boost::get( value_initialized<arg>() ) );

might help some compilers to eliminate the unused temporary objects...and as I
went to test it with MSVC++ 9.0 in my real life project I found that now
(without the mentioned change, with original boost 1.40 code), somehow, MSVC++
9.0 SP1 completely optimizes away the entire value_initialized-related
code...both the object constructor and the preceding memset...

I remember testing the issue with MSVC++ 8.0 and 9.0 when this whole discussion
began and reporting that the mentioned compilers were unable to optimize away
the memsets (with any level of optimization)...and I really can't remember what
could be the change that triggered/enabled the new/'wanted' behaviour (maybe I
installed SP1 after the original test)...

The code in question 'iterates' over a type list of ~40-50 classes with
non-trivial (but non-throwing) constructors and trivial destructors and the
functor is rather complex [involving GUI constructions (based solely on static
information from the classes thus w/o need for object instances) and thus
exception throwing]...

The above reminds me of another/'worst case' scenario for the
"value_initializing for_each" issue: if the classes in the type list have
non-trivial destructors and the functor can throw the compiler will, along with
the rest of the already mentioned baggage, also insert implicit try-catch

 "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, gregod at, cpdaniel at, john at