Re: [boost] boost::lexical_cast string to string problem - Newproposition available

From: Mattias Flodin (flodin_at_[hidden])
Date: 2002-05-25 02:14:04

On Sat, May 25, 2002 at 03:37:57AM +0200, Terje Slettebø wrote:
> Therefore, I've changed this so that it performs the usual conversion (1 <->
> '1') from/to char/wchar_t, to make it consistent with the conversion from/to
> std::basic_string.

OK. How does it handle lexical_cast<char>(123)? Throwing an exception
might be preferrable to just returning e.g. '3'.

> At the moment, this requires partial specialisation, but I intend to make a
> version that doesn't require that. However, a reasonably standards compliant
> compiler should be able to handle the current version.

Good - as a VC user I'll be looking forward to that. ;o)

> However, like I said, using implicit conversion, one overcomes this problem,
> and it's able to do the following:
> 
> int i=lexical_cast<int>(1.23); // i=1
> 
> What I'm wondering is, is it ok to perform the conversion as in the latter
> case (implicit conversion)? I would think it would be ok, and make the
> conversion more flexible, as it takes into account implicit conversions, but
> as it's a change in the semantics from the original lexical_cast, I'd like
> to get feedback on this.

At first sight, this seems to me like something that would go under
the category "implementation defined" or "undefined behaviour," since
trying to do a lexical cast between two "non-lexical" types is rather
nonsensical. Either you cast from text, to text, or both.

However, it may come to use in the case of writing generic code, where
one wants to support both strings and integers as arguments, and turn
the argument into an integer of the desired type without worrying
about its representation. So perhaps it could be viewed as an
"extended static_cast". In other words, for non-lexical types,
lexical_cast would fall back to a simple static_cast.

On the other hand, looking at dynamic_cast, it only supports the kind
of conversions for which it was intended - you can't, for instance, do
a dynamic_cast<float>(int(1)). This is supposedly to protect the
programmer from confusing the different types of casts. Is this kind
of protection necessary for lexical_cast? It could be modeled by
leaving out specializations for any casts that do not involve lexical
types on either side.

So basically there are three options: implementation
defined/undefined, static_cast fallback and compile-time errors. At
present time I'd vote for the third, on the basis that I can't see
enough of a need for being able to do non-lexical casts with
lexical_cast. I don't believe lexical_cast has enough existing usage
of the kind you describe to warrant trying to be backward compatible,
especially since Boost has never given any guarantees of the sort.

/Mattias

-- 
Mattias Flodin <flodin_at_[hidden]>  -  http://www.cs.umu.se/~flodin/
Room NADV 102
Department of Computing Science
Umeå University
S-901 87 Umeå, Sweden
--
"Now, now my good man, this is no time for making enemies."
  -- Voltaire on his deathbed in response to a priest asking
     that he renounce Satan.