Boost logo

Boost :

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-05-25 07:37:41


>From: "Thomas Witt" <witt_at_[hidden]>

>On Saturday 25 May 2002 09:14, Mattias Flodin wrote:
> On Sat, May 25, 2002 at 03:37:57AM +0200, Terje Slettebø wrote:
> >
> > 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,"

>Having such a fundamental thing implementation defined is asking for
trouble.

I agree.

However, the question is really whether or not to allow implicit
conversions. These are well-defined in C++, so there's no implementation
defined case here.

> since
> trying to do a lexical cast between two "non-lexical" types is rather
> nonsensical. Either you cast from text, to text, or both.

>I strongly disagree. Conceptually lexical_cast converts between types that
>have a textual representation, in c++ speak have suitable operator>><<
>overloads.

I understand that point. Thanks for the clarification. That kind of gives a
better focus on what lexical_cast should actually do. If both source and
destination are lexical, the original version of lexical_cast doesn't give
correct conversion for some values (if they contain whitespace), so that may
be changed, in any case.

So, if I understand you right, the original version of lexical_cast does the
right thing (possibly with the mentioned modification if both source and
destination are lexical). Any extra functionality should then possibly be as
a separate component, like interpret_cast, which gives a "general"
conversion, as Kevlin Henney mentions in the docs about future directions.

Regards,

Terje


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk