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-08 15:51:22

"Domagoj Saric" <dsaritz_at_[hidden]> wrote in message 
news:hkn7c1$oq0$1_at_ger.gmane.org...
>>> aux::unwrap(f, 0)(arg());
> - suffers from 'possible undefined behaviour'

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

>>> 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)...

Anyways...it 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 
blocks...

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