From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-05-11 10:23:18
Dave Dribin wrote:
> On May 5, 2005, at 2:55 PM, Andrey Melnikov wrote:
>
>> Semantically convert_to is a different operation. Safe C++ way to do
>> itoa has nothing to do with serialization.
>
> Working with windows and configuration files, in my experience, at
> least, requires handling of invalid values. They are the normal case,
> not an exceptional case. And from reading the lexical_cast
> documentation, you'd think this is the library to use. Apart from the
> name containing "cast", lexical_cast does what I need: converting
numbers
> to and from strings.
I agree with the need for safe conversion function with error
indication, and with other lexical_cast design goals stated in
documentation. I just don't want slow approach with temporary
std::stringstream to be used for simple conversions.
Instead, I want faster lexical_cast() specializations for built-in
types, and additional lexical_cast_nothrow() function.
>> I think we can leave lexical_cast alone as it is, but add separate
>> functions for safe conversions between ascii and binary representation
>> of numbers. These functions should be fast and properly named
>> according to their semantic. Performance requirement can also force us
>> to implement additional interface with error flag instead of throwing
>> exceptions. convert_to<int>("abc") can be so fast that in some
>> applications overhead of throwing an exception will be very noticeable.
>
> That would work, as well. But I'm thinking that convert_to would need
> to fall back to lexical_cast for conversion that do not contain a
> string. If we want to concentrate on the conversion to and from
> strings, maybe names like string_to and to_string would be more
> appropriate:
>
> int n = string_to<int>("50");
> int httpPort = string_to<int>("invalid conversion", 80);
>
> And the converse:
>
> string message = "Connecting to server: " + host + ":" + to_string(80);
I introduced to_string and from_string not only because I dislike
"lexical_cast" name. The main reason is that current extensibilty
framework is too heavyweight. So I proposed to introduce a separate
family of functions which wouldn't require operator << and operator >>
(or, more precicely, ostream/stringstream) for extensibility.
For example, an UDT could just specialize an internal template class to
allow faster conversion using std::string, or use older extensibility
framework with overloaded operator >>.
On the one hand, implementation which uses std::string, can be much
faster than implementation which uses std::stringstream. On the other
hand, std::stringstream provides convenient methods to facilitate
serialization of complex types.
Can we stay with just lexical_cast, add lexical_cast_nothrow and
lexical_cast_default, and have both extensibility methods implemented in
a non-conflicting way?
> Actually, to_string cannot have an invalid conversion case, can it? It
> seems only going from a string can cause that.
In case of user types it can. For example, an overloaded operator <<
can refuse to serialize an object with invalid state.
> And as for performance being an issue, it probably is in some cases. In
> the cases where I've used string to int conversions and vice vera,
> performance has not been critical and stringstreams have been just fine,
> though. I started using lexical_cast because it made my stringstream
> code easier to read.
Well, function performance is always an issue only in some usage
scenarios. I understand that parsing config files doesn't have high
performance requirements.
I actually don't use lexical_cast directly. I use boost::date_time on
large data volumes, and it happened that overhead of using
boost::date_time was significant even despite I/O was the bottleneck
too. Performance profiling showed that date_time was among critical
functions. When I looked inside the source, it turned out that I could
increase overall performance a lot by patching boost::lexical_cast and
boost::tokenizer libraries... Now I want these issues to be fixed in
main boost source tree so I won't need to patch next releases myself to
get the performance I need.
Andrey