Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-06 07:30:10

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.  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.

> 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;

> 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;

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());

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com





IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.