On Fri, Feb 27, 2009 at 11:14 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
On Friday, February 27, 2009 2:06 PM Emil Dotchevski wrote:
On Fri, Feb 27, 2009 at 10:52 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
On Friday, February 27, 2009 1:48 PM Emil Dotchevski wrote:
On Fri, Feb 27, 2009 at 5:30 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
The framework uses IOStreams to do its work. I believe the conversion functionality for the uuid type is captured via:
namespace user { class uuid;
template <class Stream> Stream & operator <<(Stream &, uuid const &); }
If operator<< was a reasonable to-string alternative, we wouldn't be needing a library for it.
That is the purpose of the insertion operator: it produces a character sequence from the right hand argument.
No, its purpose is to implement dumping of objects in streams, in terms of other existing operator<< overloads. This can also be used to convert to string, but the streams framework is rather clumsy to use when you need a std::string.
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. :)
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. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode