Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-05-10 02:38:58

> Message du 10/05/11 02:25
> De : "Vladimir Batov" 
> A : boost_at_[hidden]
> Copie à : 
> Objet : Re: [boost] [review] string convert
> 
> > Stewart, Robert  sig.com> writes:
> > 
> > convert::to(), or not and it is still readable. That function can, one
> > way or another, provide support
> > for manipulators while convert_cast() can skip them. That means that
> > to() can be used for
> > stream-based conversions and convert_cast() for non-stream-based
> > conversions. Whether the
> > latter must provide any l10n support is for others to determine as I simply
> > don't know enough to say.
> 
> 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 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.

> 
> > If that's a decent API, and since it represents the combination of the
> > functionality in both Vicente's and
> > your library, perhaps the two of you could collaborate on it and produce a
> > new Boost.Convert proposal. 
> > (I'd prefer Boost.Convert to Boost.Conversion because the namespace name is
> > shorter and more useful
> > when reading names like "convert::as.")
> 
> I do not want to slow Vicente down and I am happy for Vicente to steam ahead if
> he feels like it... if he is willing to cover use-cases described in the
> original 'convert' proposal. Although so far I did not get that impression that
> Vicente was covering the original 'convert' cases. If that's changed and I
> missed it, great.

As you, I'm ready to add whatever feature I think is useful to the users that preserve my library main intent. I have presented some proposals for the non default constructible class, for the no-throw semantics and for the fallback that follows the initial design. I think that stream based conversion need special treatment as it is the case for numeric conversions and I don't want to play in this game. Recall again the for me the main difference between the libraries was the default behavior. I you want to change the default behavior of Boost.Convert, then the things could be quite different.

Best,
Vicente