> From: Stiphane Bronsart [mailto:stephane.bronsart@bea.be]
>
> But if do a call like this :
>
> signed short int i = lexical_cast<signed short int>("60000")
> no exception is
> throw !
> i is assigned a value of -5536

The value of i is actually undefined, but in this case, the value wraps (and does so on most implementations). lexical_cast does not perform range-checking on numeric types.

 
> It is possible to catch some error ?  How ?
> If I have to scan the string before calling lexical_cast, it is not so
> useful...

Everything's possible...if you're not concerned about the efficiency penalty, consider lexical_cast:ing the returned value back to a string, and compare that to the original value. If there is some sort of guarantee on the input value, so that you can use a numeric type that can hold all possible input values, lexical_cast to that type, followed by a numeric_cast to the actual destination type. numeric_cast performs checks for positive and negative overflow, and does what you're looking for (but only for numeric types). Wrap this up in a cast function of your own, and that should do the trick.

> Is the use of  stringstream (see implementation of
> lexical_cast) not to
> heavy ?
> What say boost about that ?

Nah, personally I don't think so. While it can be argued that there is potential for optimizations by using lower level constructs for known conversions, that defeats the generality of the solution. The concept of streaming makes lexical_cast usable with UDT:s; often without any extra coding. IMO, that's a real plus. Finally, the elegance of the solution is just too beautiful to change :-).

Bjorn