$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [review] string convert
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-05-10 18:09:35
> Message du 10/05/11 23:50
> De : "Vladimir Batov"
> A : boost_at_[hidden]
> Copie à :
> Objet : Re: [boost] [review] string convert
>
> > Vicente BOTET wanadoo.fr> writes:
> > ...
> > I suspect you have not understood my concern. The question is what is the
> > default behavior of the conversion
> > of two UDT Source and Target if the library is not aware of.
> >
> > Is it
> >
> > return Target(val)
> >
> > or
> >
> > Target res;
> > ios << val;
> > ios >> res;
> > return res;
> >
> > ?
> >
> > IMO this difference in behavior merits two different functions.
>
> The second approach of converting two UDTs (which could be done with
> lexical_cast) never made sense to me. It still looks bizarre and I doubt anyone
> deployed it ever. lexical_cast stream-related business is sensible as long as
> the string type is in the picture. In fact, I do not believe the ios-based
> conversion of 2 UDTs is by design. I see it more of a side-effect of
> lexical_cast stream-based approach to to_string from-string conversions. After
> all, it's not called *lexical* for nothing. The original 'convert' did not have
> the second behavior... well, it did not have the first -- Target(val) -- either.
> :-) That generalization seems sensible.
Do you mean that is without a specialization is a compile error in the original library? What are your project for the future library?
Best,
Vicente