Re: [boost] boost::lexical_cast<bool>("true");

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2003-05-08 10:36:21

In message <20030506144102.GWQM17933.amsfep14-int.chello.nl_at_localhost>,
tslettebo_at_[hidden] writes
>> From: Markus Werle <numerical.simulation_at_[hidden]>
>> 
>> The feature mentioned in the subject is missing in boost.
>> (actually it throws)
>> I propose adding something simmilar to the (incomplete) stuff below.
>> 
>> template <typename Source>
>> class lexical_stream_common_stuff<bool, Source>
>
>This could be a possibility. Rather than testing for the strings "true" and 
>"false" (which wouldn't respect locale), it may be better to set the ios_base 
>"boolalpha" flag, which reads and writes bool as "true" and "false" (or whatever 
>is set for the locale).
>
>However, the question is that some users may want to read/write "0" and "1", 
>instead.
>
>This has the same problem as other stream configuration, such as setting the 
>number base, etc.

Sensitivity to the global locale is important, so this would certainly
have to be a consideration. However, it is not clear to me that "true"
and "false" are necessarily better than "1" and "0" because that result
is rarely surprising or awkward in the context of I/O streams. This
differs from either precision loss for numerics or whitespace quirks for
text types, which are the two obvious exceptions made in lexical_cast at
present.

Years ago I considered the bool issue, and rejected it the need for such
special casing because it felt like more of a "would be nice if" than a
"must have" feature. I am not sure that has changed.

There are two basic directions in which I intend to evolve lexical_cast
that may be relevant here:

(1) Formulate the general model of conversion that is used in a way that
allows text and numeric types to be considered part of a model rather
than exceptions to it. In the past suggestions for lexical_cast have
tended to focus on point solutions or have been implementation focused.
It is time to tidy up the underlying conceptual model and make it
explicit. However, I am not overly keen on adding Boolean types as an
additional category that needs to be modelled.

(2) Allow some form of parameterisation when converting -- but, just to
be clear, this would not result in changes to the core lexical_cast
function template or the addition of extra arguments. The motivation for
this is the ability to use locales other than the global one, and is
something that I have been discussing with Thomas Witt. Handling format-
related flags would be a logical extension of this, and might be the way
to address any need to work with bool as "true"/"false" rather than
"1"/"0".

Kevlin
____________________________________________________________

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