Subject: Re: [boost] Boost.Conversion - pre review request
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2011-07-13 18:53:10
On Jul 11, 2011, at 12:59 PM, Vicente Botet wrote:
> Yes, this is exactly the point. There couldn't be a conflict in the whole
> program. Library authors could document the conversions choices they have
> taken, but the use of a non-consensual conversion will make the library less
> I don't think that Boost.Conversion can provide a string-to-type conversion
> that is configurable. It could provide one if there is a consensus of a
> default. We should see Boost.Conversion customization as if we were adding
> some methods to one of the classes. For the string to float conversions, it
> is as if we were adding
> explicit operator float() const;
> to the std::string class.
Why not provide the functionality in mutually-exclusive headers, e.g. #error out in conversion/boost/coerce-strings.hpp if you see that lexical_cast-strings.hpp has already been included? This wouldn't prevent all ODR violations but it would catch any in the same compilation unit.
I suppose there is a fancier metaprogramming way to detect conflicts in general (within a TU), but this is cheap.
And then define none by default. That seems to be harmonious with the rest of the design, where one #includes exactly the functionality one needs.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk