Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-05-06 08:07:00

> Message du 06/05/11 13:31
> De : "Stewart, Robert" 
> A : "'boost_at_[hidden]'" 
> Copie à : 
> Objet : Re: [boost] [review] string convert
> 
> Vicente BOTET wrote:
> > De : "Stewart, Robert"
> > > 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.
> 
> I see.
> 
> > > - 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.
> 
> I mentioned before that overloading can avoid such concerns. 

You are right, overloading could be used, I missed this point.

> If you don't supply any formatting, then you get the simpler implementation. If you do, you get the more complicated implementation.
> 
> Maybe there should be distinct names for each set in order to clarify that they work differently. Obviously, to use manipulators requires the use of a stream. Without them, other implementations are possible, though some l10n functionality is needed still for string<->type conversions.
> 
> > 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.
> 
> Maybe. First, there's the lexical_cast approach to always convert (or, in the modern interpretation, as if) via a stream. In that design, manipulators can influence the resulting conversion. Second, string<->type conversions are an extremely important use case.

lexical cast hides the stream usage, but we have 

ios << source; 
ios >> target;

If we want to support type-to-type via stream and manimulators we will need to be able to do in the implementation

ios << omn_1 << ... << omnp_n << source; 
ios >> imnp_1 >> ... >> imnp_k >> target;

As far as I perceive the Boost.Convert library the manipulators are used either to convert to a string or from a string. I have not see deeply hwat allows the converter class. Can someone tell me if the reviewed interface can be used to make such type-to-type conversions?

> > In another post I proposed to use an istream
> > proxy when converting from a string to a type
> >
> > as_istream(str) >> std::hex >> i;
> 
> I do find that interesting, but does it offer enough benefit relative to the following?
> 
> std::istringstream s;
> s >> std::hex >> i;

I have no problems with that. I was just proposing a one-line solution.

> > 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;
> 
> That is troublesome. However, we could create a more efficient form of std::ostringstream:
> 
> string str;
> converting_ostream(str) << std::hex << i;

Yes this could be useful. 

> Obviously, move semantics make using std::ostringstream just as efficient, though slightly less convenient:
> 
> std::ostringstream s;
> s << std::hex << i;
> string const str(s.str());
> 
> If operator <<() returned std::ostringstream, it could be streamlined still more:
> 
> string const str((ostringstream() << std::hex << i).str());
It usually is.

We could also define an operation that takes the stream and extract a type returning the value instead of requesting a variable

int i = extract(str >> ios >> std::hex) 

string str = extract(ios << std::hex << i);

With this interface we can add in a single expression output manipulators and input manipulators.

Best,
Vicente