"Peter Dimov" <pdimov@mmltd.net> wrote in message news:00c501c414c8$4d7aba80$1d00a8c0@pdimov2...
Jonathan Turkanis wrote:
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:004101c41369$2ca8cb90$1d00a8c0@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