Boost logo

Boost :

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-05-09 04:24:13

Andy wrote:
> "Peter Dimov" <pdimov_at_[hidden]> wrote in
> news:01c201c7919b$0a73fb40$6407a80a_at_pdimov2:
>> Andy wrote:
>>> "Peter Dimov" <pdimov_at_[hidden]> wrote in
>>> news:00b601c790ad$8e357b00$6407a80a_at_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>
    static guid_impl_t const& null()
    { return g_null_guid; }

    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

Boost list run by bdawes at, gregod at, cpdaniel at, john at