Re: [boost] Formal Review Request: Boost.Convert

Subject: Re: [boost] Formal Review Request: Boost.Convert
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-02-28 06:14:25

Emil Dotchevski wrote:

>> I hope you're not being purposely obtuse.  I raised the insertion
>> operator as the spelling of the hook for the library because the
>> library will use a std::ostringstream to produce the (formatted)
>> output.  Since UDTs frequently provide such an operator, the
>> convert code will piggy back on those operators easily, thus
>> turning them into a handy means of converting to a string.
> 
> Operator<< overloads don't solve the problem of converting to string 
> well. Boost::lexical_cast isn't either. I was assuming that anyone
> who considers yet another to-string conversion interface was on board
> with that. :)

The operator<< does its job very well as a simple and widely-used fall 
back method of to-string conversions. I agree with Robert that the 
Boost.Convert library (oh, well, the one that I have in mind, at least) 
should support user-defined operator<<. However, there should also be a 
way to provide a more fine-grained conversion implementation, for 
example, with these Boost.Parameter customization options.

>> My point was it was a loop.  How do you resolve it?
> 
> The loop case is when you call convert. Basically you need to detect 
> if the overload resolution for operator<< will bind the generic 
> operator<< overload provided by convert, and in that case induce a 
> compile error.

I guess that is only possible when instantiating the operator<<, isn't 
it? Is that really desirable? IMO, the library should not jump over its 
head. It uses the user-provided operator<<, but it doesn't have to 
provide it.