From: Alberto Barbati (abarbati_at_[hidden])
Date: 2002-08-22 14:40:00
Terje Slettebø wrote:
> Would it really be an advantage to use "t=interpreter.str()" instead of "t
> << interpreter"? Performance, perhaps. Have you done any measurements, or
> something like that, to show that this specialisation is worthwile?
It's not just a matter of performances here. "t=interpreter.str()" and
"interpreter >> t" do two completely different things. In particular,
the latter stops at the first whitespace while the former does not. In
fact, one thing that striked me at first when studying lexical_cast is
that with the current implementation, the expression:
not only does not return the string "hello, world" but throws an
exception because of the space. It's very counter-intuitive, IMHO.
> In addition, this would only work for "char" character types. It would have
> to be generalised to deal with other character types. Nevertheless, that's
> possible, too.
I'm now aware of the char/wchar_t/whatever problem (I wasn't before
posting). Hot stuff, indeed.
I had a look at your proposal. The main interesting difference between
the two approaches (correct if I'm wrong, please) is that your proposal
always consider Target/Source as a pair or template arguments, therefore
in order to provide a specialization for one type you probably need
partial specialization, which could be unavaible. My approach de-couples
Targets from Source, thus avoiding the inconvenience.
> Since Kevlin hadn't got around to reviewing the original proposal, I waited
> with any changes. However, as it now seems he may do it, and due to the
> release date extension, I'll look into adding this, as well, and look into
> the proposal in this posting.
In fact the two approaches could be merged to have both de-coupling and
solve the char/wchar_t: we could use a machinery like the one in your
proposal to choose the "right" interpreter (think about Target and
Source "negotiating" the best one), then use the two inserter/extractor
helper functions. What do you think?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk