Andy wrote:
"Peter Dimov" <pdimov@mmltd.net> wrote in news:01c201c7919b$0a73fb40$6407a80a@pdimov2:
Andy wrote:
"Peter Dimov" <pdimov@mmltd.net> wrote in news:00b601c790ad$8e357b00$6407a80a@pdimov2:
null()/nil() are actually redundant and only contribute thread safety problems. The default constructor already creates a NULL UUID, as it should.
I agree that they are redundant. I am not pushing them, but just wondering why they would contribute to thread safety problems since they return a constant object?
Because of the local static variable.
Ah! Multiple threads may try to initialize the variable at the same time. If it could be initialized correctly, there wouldn't be a problem.
... which people have been writing essays about (i.e. thread-safe local static initialization). You could use boost::once, but that feels like rather heavy-weight for this specific case. FWIW, I like the concept of an explicit "null" object instead of relying on a default-constructed guid being equivalent to a null one (syntactic sugar). If you decide to go for a non-header only implementation, you could always define the "one" null guid as a static const member instead (or simply define it at namespace-level in one of the sources). You could also define the real implementation of guid as a template: ----------------------- namespace boost { namespace detail { template<int dummy = 0> class guid_impl_t { public: static guid_impl_t const& null() { return g_null_guid; } private: static guid_impl_t const g_null_guid; }; template<int dummy> guid_impl_t<dummy> const guid_impl_t<dummy>::g_null_guid = guid_impl_t<dummy>(); } // namespace detail typedef ::boost::detail::guid_impl_t<> guid; } // namespace boost -------- Don't know if that's standard-compliant though. / Johan