Re: [boost] [lexical_cast] performance related feature

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-06-05 05:21:21

>From: "Pavel Vozenilek" <pavel_vozenilek_at_[hidden]>

> lexical_cast<> constructs and destroys std::stringstream
> (including dynamic memory allocation/free.)
> each time a conversion is done.
>
> Maybe specialised version of lexical_cast<> can be developed
> which takes external, existing stringstream instance as
> template parameter and reuses it.
>
> Very rough idea:
>
> template<typename Target, std::stringstream& ss, typename Source>
> Target lex_cast(Source s)
> {
>     // clear ss
>     ss << s;
>     Target t;
>     ss >> t;
>     return t;
> }
>
> extern std::stringstream ss;
> std::stringstream ss;
> ...
> int a = 99;
> std::string s = lex_cast<std::string, ss>(a);

This used to be addressed in the "Future Directions" part of the
lexical_cast documentation, but I see that that section is now removed.
Maybe it should be put back, at least the relevant parts? Kevlin?

>From the CVS, that section used to read:

--- Start quote ---

Future directions

- Improved string handling, correctly accommodating wide character strings,
incompatible basic_string types, and empty strings.

- Optimize the use of a stream away for identity conversions.

- An interpret_cast that performs a do-something-reasonable conversion
between types. It would, for instance, select between numeric_cast and
lexical_cast based on std::numeric_limits<>::is_specialized. This would be
an interesting project, but there are no concrete plans to pursue this at
the moment.

- It is also worth mentioning future non-directions: anything that involves
adding extra arguments for a conversion operation is not being considered. A
custom keyword cast, such as lexical_cast, is intended to look like a
built-in cast operator: built-in cast operators take only a single operand.
Where a higher degree of control is required over conversions, the standard
stringstream offers a more appropriate path. Where non-stream-based
conversions are required, lexical_cast is the wrong tool for the job, and so
it won't be special-cased for such scenarios.

--- End quote ---

Note "anything that involves adding extra arguments for a conversion
operation is not being considered."

Regards,

Terje