On Sun, Dec 30, 2012 at 3:39 PM, Vicente J. Botet Escriba
Le 27/12/12 21:32, Felipe Magno de Almeida a écrit :
[snip]
I think double-free of allocated memory is quite possible, but I think anything is possible depending on implementation details. I rather not rely on implementation details.
I don't see any allocation there. Boost has a lot of code that depends on compiler implementation details.
I might be wrong about allocation and deallocation on most implementations. I'm not against using implementation details, but they should be explicit, and ifdef'ed with a default implementation for other compilers.
Also, I was expecting race conditions to be taken more seriously than to wait for bad behavior to appear. It is, afterall, a correctness issue.
You are right. the issue should be taken in account.
Does the following schema extracted from Boost.Units solve the issue or it works only for POD types?
namespace detail {
template<bool> struct xalloc_key_holder { static int value; static bool initialized; };
template<bool b> int xalloc_key_holder<b>::value = 0;
template<bool b> bool xalloc_key_holder<b>::initialized = 0;
struct xalloc_key_initializer_t { xalloc_key_initializer_t() { if (!xalloc_key_holder<true>::initialized) { xalloc_key_holder<true>::value = std::ios_base::xalloc(); xalloc_key_holder<true>::initialized = true; } } };
namespace /**/ {
xalloc_key_initializer_t xalloc_key_initializer;
} // namespace
} // namespace detail
/// returns flags controlling output. inline long get_flags(std::ios_base& ios, long mask) { return(ios.iword(detail::xalloc_key_holder<true>::value) & mask);
}
I might not be knowledgeable enough to comment, but this seem a very strange hack for the initialization order fiasco. [snip]
Boost.System will depend on Boost.Thread and Boost.Thread already depends on Boost.System.
I see. I rather they be interdependent than to have race conditions. And I don't think call_once requires boost.system. So at least cyclic includes could be avoided.
Yes, but this will mean to have two Boost.Thread libraries boost_thread (with call_once) and boost_futures (which depend on Boost.System). I'm not against this but this will mean a new breaking change.
If call_once were made header-only, there wouldn't be any breakage. IIUC.
Best, Vicente
Regards, -- Felipe Magno de Almeida