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.