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>
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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk