8 Feb
2010
8 Feb
'10
8:51 p.m.
"Domagoj Saric" <dsaritz@gmail.com> wrote in message news:hkn7c1$oq0$1@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