|
Boost : |
Subject: Re: [boost] [uuid] Interface
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2008-12-18 22:14:18
On Thu, Dec 18, 2008 at 16:15, <Vladimir.Batov_at_[hidden]> wrote:
>
> Yes, the default lexical_cast behavior requires the default constructor.
> Having said that I've been routinely specializing lexical_cast to optimize
> away the overhead.
>
> If we do that for boost::uuid, then the user gets the familair interface
> and we have our class clean and minimal.
This seems like possibly the best idea, though it does mean extra care
will be needed to match the normal lexical_cast semantics.
I'm still not convinced that that providing the default constructor is
such a bad thing, so I would still like Andy's #define to allow it.
(Or IMHO better, a define to make it private.)
> Having said that I am honestly unsure about
>
> uuid id = lexical_cast<uuid>(str);
>
> as it seems already covered by
>
> template<typename InputIterator> uuid(InputIterator,
> InputIterator);
>
No. The input iterator constructs from the raw octets, expecting them
as in 4.1.2. Layout and Byte Order in
http://www.faqs.org/rfcs/rfc4122.html . The elements in the passed
range will be equal to those in the id.begin(), id.end() range.
>
> Can we take it one step further and replace it with a more generic:
>
> template<class ForwardReadableRange>
> [...]
>
I'm not convinced it's helpful for the constructor, but it would be a
very good plan for the name-based generators. Making those accept
string literals and std::vectors and std::strings directly would be a
very worth-while interface improvement.
~ Scott
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk