From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-03-28 13:11:01
"Peter Dimov" <pdimov_at_[hidden]> wrote in message
> Jonathan Turkanis wrote:
> > "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> > news:004101c41369$2ca8cb90$1d00a8c0_at_pdimov2...
> >> And for the string case, the downside to encoding a comparison in
> > the type
> >> is that you'll now spend a lot of time converting strings
> > most
> >> libraries - correctly - accept an ordinary std::string,
> > of what
> >> comparisons they might make underneath, or they'd expose
> > implementation
> >> details in the interface.)
> > You can expose the string as a typedef, to avoid bothering library
> > users with custom comparison policies. Most of the
> > concerns could be addressed by relaxing the requirement that
> > traits_type match extacly in basic_string member functions which
> > basic_strings as arguments -- at least for those which don't
> > comparison.
> Nice theory, but nobody has ever tried it in practice.
Sure -- it's not practical with the current basic_string.
> Not that there's any
> need to. std::string works, and nobody uses the 'Traits'. Besides,
> still introduce unneeded string copies.
These copies would mostly happen when a string is passed from one
library or API to another; copying would occur there anyway, except
with reference-counted implementations.
Anyway, I'm not really advocating this style of programming. I just
don't see why it should be made impossible by not providing a traits
parameter (with all the junk removed, of course) .With basic_string,
it's easy to ignore the traits parameter if you don't want to use it,
as you've said.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk