On Fri, 22 Jan 2010 04:06:40 -0600, Niels Dekker - address until 2010-10-10 <niels_address_until_2010-10-10@xs4all.nl> wrote:
Aleksey Gurtovoy wrote:
[...] I think we should revert to the approach of applying the workaround conditionally for the specific compilers known to be buggy, and just those -- especially if we have tests to discover these bugs should they return.
As for the specific compiler versions:
- GCC bugs #30111 and #33916 has been fixed in 4.4 and 4.2.4 correspondingly [1], [2].
So GCC 4.2.4 still needs the memset, but GCC >= 4.4.0 can do without it, right?
Yep.
- MSVC bug #100744, despite being marked as "Closed, Won't Fix" [3], has actually been fixed in VC9 [4].
I'm sorry, MSVC bug #100744 is still there, even though #335987 has been fixed. VC9 deals with POD types correctly, but may not do so for non-POD aggregate class types.
Hmm, you are right, it doesn't.
- Borland bug #51854 is also reported as being fixed in build "12.0.3140.16150" [5]
Looks promising. Do you know how to do a compile-time check if Borland/Codegear build >= 12.0.3140.16150?
I don't, but may be somebody more familiar with C++ Builder can help us.
Anyway, I wouldn't mind if the memset call in utility/value_init.hpp would become conditional, for example as follows:
#ifdef BOOST_VALUE_INITIALIZATION_NEEDS_MEMSET std::memset(&x, 0, sizeof(x));
#endif
What do you think? And would it be okay to you to have such a macro, BOOST_VALUE_INITIALIZATION_NEEDS_MEMSET, defined in boost/config/compiler/, for those specific compiler versions?
Sounds good to me. John? -- Aleksey Gurtovoy MetaCommunications Engineering