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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk