Re: [boost] lexical_cast with default value

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