Re: [boost] [review] string convert

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

> Message du 05/05/11 22:57
> De : "Matthew Chambers" 
> A : boost_at_[hidden]
> Copie à : 
> Objet : Re: [boost] [review] string convert
> 
> 
> 
> On 5/5/2011 3:17 PM, Vicente BOTET wrote:
> >
> >
> >
> >> Message du 05/05/11 19:48
> >> De : "Stewart, Robert"
> >> A : "'boost_at_[hidden]'"
> >> Copie à :
> >> Objet : Re: [boost] [review] string convert
> >>
> >> Vicente BOTET wrote:
> >>>
> >>> are we discussing here a generic interface from type-to-type or
> >>> one that uses an intermediary stream to make the conversion?
> >>
> >> I've been considering it the former. Why does using a stream to make the conversion affect that?
> >
> > The fact that we want to add some formatting parameters, apply manipulators and so on to a generic interface disturb me.
> >
> >> - T convert_cast(S, formatting = none); can throw
> >> - T convert_cast(S, T, formatting = none)
> >> - optional name_me_1(S, formatting = none)
> >> - optional name_me_1(S, T, formatting = none)
> >> - pair name_me_2(S, T, formatting = none)
> >
> > I would prefer to don't pay for these defaulted parameters in the generic case.
> >
> > Maybe I'm wrong, but the manipulators are only useful when converting from a string or to a string. If this is the case, all the stream stuff should be moved to a string conversion interface. I would even prefer that the stream part stay away and independent. In another post I proposed to use an istream proxy when converting from a string to a type
> >
> > as_istream(str)>> std::hex>> i;
> >
> > For conversions from a type to a string, we can use an ostream proxy, which is implicitly convertible to string.
> >
> > string str = as_ostream()<< std::hex<< i;
> Conversions from strings to primitives and vice versa will vastly outnumber other type-to-types. If 
> we're going to bias the interface in some way, I believe in doing it for the general case. And 
> unless I'm missing something, the as_xstream syntax has the same implicit conversion problem that 
> the convert::from() syntax has.

Hrr, you are right for the as_ostream It will be great if we could write

str << as_ostream() << std::hex<< i;

and 

str >> as_iistream() >> std::hex>> i;

In these cases there will not be implicit conversion.

Another possibility is to have a string converter that follows the numeric converter pattern
template (*...*)
struct converter
{
static result_type convert ( argument_type s ) ;

result_type operator() ( argument_type s ) const ;

// other specific functions
}

> Other kinds of type-to-type conversion that aren't better served by numeric_cast (unless you're 
> proposing to wrap numeric_cast with boost.conversion?) are practically edge cases, aren't they? We 
> can allow the interface to support them, but we shouldn't reduce it to the lowest common denominator 
> when the general requirements are higher.

Well, this is the intent of my library Boost.Conversion. If you think that this is not useful, I have lost client ;-)

> Also, the string conversion will be optimized for the common cases: integral<->string and 
> floating<->string. Lexical_cast's current stream-only implementation won't suffice. Basically, I 
> think type-to-stream-to-type should be the fallback mechanism if no specialization is available. And 
> of course sometimes even that fallback mechanism will fail with UDTs.

Boost.conversion fallback mechanism for convert_to is a call to the explicit conversion Target(rhs). If the user wants another kind of conversion he must overload the convert_to function. If the user think that two types can be converted using lexical_cast, numeric_cast or other specific mechanism, he will need to make an overload and forward to the corresponding cast.

I like this generic interface, as it allows to name all the conversions the same way. If more sophisticated conversion are needed it will be better to use a string converter, numeric converter or any other specific mechanism.

Well, this is how I see this conflicting subject.

Best,
Vicente