Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at