Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-05-10 13:00:41

> Message du 10/05/11 09:11
> De : "Vladimir Batov" 
> A : boost_at_[hidden]
> Copie à : 
> Objet : Re: [boost] [review] string convert
> 
> > From: "Vicente BOTET" 
> >> De : "Vladimir Batov"
> >>
> >> I am not sure why that distinction has to be made. Now that converters 
> >> are gone
> >> and all parameters are provided in one call, the implementer knows what
> >> conversion is needed. That is, if there are no 'format_' parameters 
> >> specified,
> >> then, say, spirit-based quick conversion is applied. As soon as I see 
> >> 'format_',
> >> then I fall back to stream-based. So, all we seem to need is convert::to.
> >
> > Vladimir, what is the default behavior of your convert::to proposal with 
> > only one
> > source argument?
> > If it is a call to the conversion operator then the two approaches are 
> > just differing
> > at the interface level and we should have just one. If the default 
> > behavior is the
> > equivalent of a lexical cast whatever technique is used, the the libraries 
> > have
> > different semantics and I need to have the Boost.Conversion default 
> > behavior.
> > So we will need two libraries.
> 
> Err, you mean int i = convert::to(str); right? Does not it work as 
> lexical_cast (for string-to-int) as I do not think there are other choices. 
> I am not sure what "a call to the conversion operator" means. If see this 
> call returning int() or some default_value, then I firmly believe that 
> is not right as you cannot possibly anticipate what the user might consider 
> an appropriate default.

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.

I it 

return Target(val)

or

Target res;
ios << val;
ios >> res;
return res;

?

IMO this difference in behavior merits two different functions.

Best,
Vicente