Boost logo

Boost :

Subject: Re: [boost] [uuid] Interface
From: Vladimir Batov (batov_at_[hidden])
Date: 2008-12-24 15:15:04


> But there's always the other way to resolve a disagreement over
> semantics: parametrization!
>
> What if there was an initialization policy? boost::uuid could be
> boost::uuids::uuid<no_default>, since I think there are a fairly large
> number of use cases that don't need one at all. lexical_cast<uuid<T>
>> could be overloaded to call lexical_cast<uuid<aggregate> >, the
> fastest option. People could have map<string, uuid<nil_default> > if
> they want the "if (m[foo])" shortcut. And you could have
> uuid<native_generator>.

It's got me thinking about uuid parametrization and I think there is part of
it that I am warming up to and the other part that I am unsure of. What I
think we indeed could parameterize on might be the generator, i.e.

template<class Generator>
uuid { ... };

Reasoning behind it is that it is probably most likely that the developer
once chosen a particular generator will stick with it throughout its
application rather than juggling different generators at run-time.
Therefore, parameterizing of the generator seems to make the code more solid
and easier to maintain as the variability (and the room for an error --
calling the wrong generator) out of the equation. The "bad" thing is that
this seem to better fit the def. cnstr (with generating behavior):

template<class Generator>
uuid
{
    typedef ... nil_type;
    static nil_type nil;

    uuid()
    {
        typename Generator::range range = Generator::generate();
        this->initialize(range.begin(), range.end());
    }
    uuid(nil_type)
    {
        for (boost::array<char, 16>::iterator i = data.begin(), end =
data.end(); i != data.end(); *i = 0, ++i);
    }
};

As for parameterization of policy, then I am honestly not sure. As a proof
of the concept it indeed sounds good. My fear though is that for
maintainability/readability purposes that might be a nightmare.

Having said that, that my view about hte def. cnstr and its behavior is just
my view. If there is a good number of people thinking that the def. cnstr
wih the nil behavior might be better/more practical, we should adapt the
view, clearly document that and move forward. The certainly good part of it
it'll make a lot of things easier to implement.

Best,
V.

 


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