On Thu, Dec 18, 2008 at 16:15, <Vladimir.Batov@wrsa.com.au> 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