(Off list) Re: [boost] more flexible lexical_cast

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-08-22 15:15:03

> > > > At Thursday 2002/08/22 03:44, you wrote:
> > >
> > > These attributions are not very helpful.  Who's "you?"
> >
> > Me. :)
>
> Unfortunately, his attribution line doesn't make that clear.

I know. Some email-programs does it that way, which is not very helpful for
mailing lists.

Ironically, your own email-header in this posting was rather funny,
appearing in the message, itself (at least for me, with OE), and with
reply-to using your address, rather than Boost.

> > > The swap is still valuable because it swaps the contents between
widget
> > and the
> > > temporary returned by ost.str().  The alternative, assigning the
temporary
> > to
> > > widget, means that a copy of the temporary's contents is written to
widget
> > and
> > > then the temporary is destroyed.
> >
> > But in what way would this be useful for lexical_cast?
>
> That may well be a separate question from the one I was answering!

I understand now. Since the thread was about lexical_cast, I thought your
reply was, as well. But I see it was about that specific example.

> > if you have std::string as target, you have something like:
> >
> > std::stringstream interpreter;
> >
> > ...
> >
> > return std::string(interpreter.c_str());
> >
> > How will a swap help you here?
>
> My guess is that you meant:
>
>     return std::string(interpreter.str());

Yes. I mentioned that in the following mail.

> In that case, swap() is not useful, since this line makes explicit the
copy
> construction that must -- in theory -- occur anyway.  (Actually, I'm left
to
> wonder whether this tells the compiler to invoke the copy constructor,
thus
> preventing the RVO.)

I wouldn't think so, rather the contrary. By creating an unnamed temporary
(the std::string call), the compiler may elide the implicit copy
construction in the return-statement.

Actually, there's of course a much more obvious solution, come to think of
it:

return interpreter.str();

Still no need for swap. :)

> There is no place for a swap to occur as there is no named
> return value to swap with and str() already creates a copy of the
> stringstream's internal buffer.

Right. Even if str() doesn't create a copy, the return-statement will (in
the last example).

Regards,

Terje