Re: [boost] more flexible lexical_cast

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
it
> > should? I can't say I see it as completely evident that calling str(),
> > followed by copy-construction, is faster than default-construction,
followed
> > 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
"interpreter.str()."
> 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
lexical_cast_impl.

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
beneficial
> as you can avoid copying the buffer contents once:
>
>     std::string str;
>     str.swap(interpreter.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
str, and
> 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..."  :)

Regards,

Terje