From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-03-28 13:11:01
"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:00c501c414c8$4d7aba80$1d00a8c0_at_pdimov2...
> 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
(because
> > most
> >> libraries - correctly - accept an ordinary std::string,
regardless
> > 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
interoperability
> > concerns could be addressed by relaxing the requirement that
> > traits_type match extacly in basic_string member functions which
take
> > basic_strings as arguments -- at least for those which don't
involve
> > 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,
you'll
> 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.
Jonathan