From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-08-22 16:35:11
>From: "Rob Stewart" <stewart_at_[hidden]>
> > >From: "Terje Slettebø" <tslettebo_at_[hidden]>
> > > if you have std::string as target, you have something like:
> > >
> > > std::stringstream interpreter;
> > > ...
> > return std::string(interpreter.str());
> > This uses in fact a specialisation. Without specialisation for
> > std::basic_string as target, you'd have:
> > std::string str;
> > interpreter >> str;
> > return str;
> > The lexical_cast proposition doesn't use the specialisation above, maybe
> > should? I can't say I see it as completely evident that calling str(),
> > followed by copy-construction, is faster than default-construction,
> > by operator>>().
> Take a look at the implementation of the istream functionality invoked by
> I expect there is a great deal of overhead as compared to
> That is, unless it is specialized for stringstreams and strings.
Yeah. I looked at str(), now, and at least for STLPort, it just makes a copy
of the string buffer (implicit copy, using return by value). Come to think
of it, ">>" invokes the I/O, with what that means.
Ok, I also think a specialisation could be useful. I'll add it to the
proposition. Actually, the case with string as target already has
specialisations, so it's only a matter of adding a base class for
I also see that Alberto has posted about this, as well, now, and that
there's a correctness issue, too. That definitely makes the case for
handling this as a special case.
I'll soon upload the updated version. It'll also include Gennadiy's
speedup-suggestion, and Alberto's specialisation-suggestion, and the above.
> What's more, given the code as written above, using swap() would be
> as you can avoid copying the buffer contents once:
> std::string str;
> return str;
I understand. I also thought about that. And I thought about what you
suggest below here. :)
> That approach avoids having to copy the contents of interpreter.str(), a
> temporary, to str. Instead, the temporary's contents is handed over to
> vice versa. That's a clear win.
> OTOH, the following would be just as efficient and is far simpler to boot:
> return interpreter.str();
*chuckles* Just as I had sent my own reply, containing this suggestion, I
get this posting. "Great minds..." :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk