Re: [boost] Re: lexical_cast "Future directions"

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-12-28 21:18:08

>From: "Early Ehlinger" <earlye_at_[hidden]>

> As a devil's advocate, consider, e.g., Borland's AnsiString class (part of
> their VCL and CLX libraries, basically a class that represents the
intrinsic
> String type in Pascal/Delphi):
>
> AnsiString foo = "Hello there";
> std::string str = boost::lexical_cast< std::string >( foo );  // exception
> for same reason!
>
> This leads me to wonder if there isn't a more generic solution to the
> problem.  For example, it might be useful to have a mechanism to determine
> if source is a string type and if so, use an implementation that looks
> something like this:
>
> std::stringstream temp;
> temp << source;
> return TargetType( temp.str().c_str() );
>
> When I say "string type", I mean any type that represents the concept of a
> string, not just those that are implemented via std::basic_string.  Not
sure
> what exactly the best way to do this is; perhaps a lexical_cast_traits<>
> template that the user must provide to help out?  So right after I include
> the definition of AnsiString, I could do something like this:
>
> template<> struct lexical_cast_traits< AnsiString > : public
> lexical_cast_string_type { };
>
> And now lexical_cast would "know" that AnsiString is a string type.
>
> Similar things could be done to support CString from MFC as well as the
> zillions of other string implementations out there.

Thanks for the feedback. I'll look into this.

This exact solution would work as long as the other string-types implements
the c_str() member function, like std::string. The user might also provide
an implementation of the conversion (or specification of which to use), if
the type to be used doesn't have this interface. Any type that may output
whitespace, could make problems when reading it into a string.

It's possible to specialise lexical_cast_impl, to achieve the above (but as
mentioned, this isn't documented, yet), and this has been suggested to be
changed to a trait, instead, like you suggest above.

I'll update the proposal with the various suggestions that have come, and
write the docs for it, and I'll post a notice here when I've done it.
That'll give us something concrete to discuss. :)

Regards,

Terje