[boost] Re: boost::lexical_cast string to string problem - New proposition available

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2002-05-26 13:27:07

In article <1a4901c20256$e51f1e20$60fb5dd5_at_pc>, Terje Slettebø
<tslettebo_at_[hidden]> writes
>Following a suggestion at the Boost User's list, I've updated the
>lexical_cast version in the Boost files section
>(http://groups.yahoo.com/group/boost/files/lexical_cast_proposition/) to use
>implicit conversion, where possible. This means it uses the fastest and most
>accurate conversion available, and only resorts to using stringstream when
>it has to.
>
>It uses boost::is_convertible for this. Even if that may not work on all
>compilers, if it doesn't work, it will just resort to using stringstream.

This seems to roundly defeat the point of lexical_cast, and I'm afraid
that these changes would not be acceptable. For a start, is_convertible
is too liberal in its behaviour. It uses purely language-based
conversions rather than on the lexical representation of the type. It
will give the wrong result in a number of easily identifiable and not so
readily identifiable situations. The only so-called 'optimisations' that
are unquestionably reasonable are identity conversions.

>However, this does mean that the semantics is changed slightly. In the cases
>where an implicit conversion exists, it may give a different result than if
>not, in the case of char/wchar_t. Without implict conversion, you get 1 ->
>'1'. With implicit conversion, you get 1 -> 1 (ASCII 1). As far as I can
>tell, this only affects conversions between char/wchar_t and other types,
>though. If this is a problem, please let me know, and I can change it to
>make an exception for char/wchar_t.

You will end up creating a patchwork of special cases as each one is
identified in turn: char <-> int, double -> int, pointer conversions,
etc.

>The reason this is optional, is that when enabled, it relies on having a
>static stringstream object. 

These options were explored -- and dropped -- in the run-up to the
original lexical_cast release. The static option is not an option.

>- It may well make lexical_cast faster, as it avoids the creation and
>destruction of a stringstream object, each time it's called.

Convenience rather than performance is the primary reason that people
will be using lexical_cast. Introducing new and subtle forms of
incorrect behaviour is not really that attractive or convenient :->

>This way, one can implement all the features of the "wish list" in the
>previous posting in this thread, such as.
>
>- wlexical_cast - A version that can use wide characters

A separate cast function should not be required.

>- basic_lexical_cast - A version that takes the interpreter (stringstream)
>as a parameter, to support things like changing locale

Use std::stringstream.

>- Being able to set number base (dec, oct or hex). This would be implicitly
>possible using basic_lexical_cast

Use std::stringstream.

>- Being able to set precision for numerical conversions. This may also be
>done with basic_lexical_cast

The correct fix for this is to use the maximum precision. Otherwise...
use std::stringstream :->

>- Checking for change of sign, when using unsigned numbers. This is
>addressed using an integer adapter, in the other lexical_cast_propositions

I have not kept up to date with all the proposals. Do you have an
example of this issue?

>The lack of formatting is what is largely the reason I haven't used
>lexical_cast much. With control over the formatting, it may be more widely
>applicable.

Use std::stringstream :->

>Despite the extra code, to handle implicit conversions, where available, by
>examining the resulting assembly output (from Intel C++), it's in fact able
>to optimise _all_ of it away, producing indentical code as if built in
>conversions were used directly.
>
>Here's an example.
>
>int n;
>double d=1.23;
>
>int main()
>{
>n=boost::lexical_cast<int>(d);
>}

This is designed to fail with the current boost::lexical_cast. This is
intentional behaviour: there was originally a discussion about how
liberal/strict interpretation should be, and the general consensus leant
towards strict. This design decision is not about to be reversed as
there is code that depends on exactly that behaviour.

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  mailto:kevlin_at_[hidden]     mobile: [phone]
  http://www.curbralan.com        fax:    [phone]
  Curbralan: Consultancy + Training + Development + Review
____________________________________________________________