>From: "Thomas Witt" <[EMAIL PROTECTED]> > Kevlin Henney wrote: > >> > >>This is the philosophy that Kevlin and I agreed on when lexical_cast > >>was first introduced. However, I don't think it has stood the test of > >>time with real users, and it would be stupid to ignore that. I > > Agreed. I see the problem, I am just unsure with regard to the solution. > > >>suspect Kevlin feels the same way about it, which is why he has agreed > >>to review the changes in the Files area. > > > > Apologies for delays. Yes, I have to review Terje's changes and am > > guilty of not having applied myself to that task yet. In terms of the > > philosophy of the design, I think it would be reasonable to say that > > intuitive stream-based conversion is the aim, which is compatible with > > fixing whitespace issues. > > One more argument. lexical_cast may be able to provide intuitive > conversion for all std string types, but it will likely brake again for > custom string types. Even if the custom type has exactly the same > interface and semantics as std::string lexical_cast will break.
Yes. That's why the proposal is designed to be _extensible_, to allow conversions between arbitrary types. See e.g. this posting (http://aspn.activestate.com/ASPN/Mail/Message/1403188). The interface will likely change, from using "boost::detail::lexical_cast_impl" to "boost::lexical_cast_traits", which will then perform the actual conversion. This may then be specialised for new types, which will then be handled seamlessly by lexical_cast, as shown in the mentioned posting. > naggingly yours <g> No, this is good stuff. :) Regards, Terje _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost