This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFC] On the uses of less<>() in basic_string
----- Original Message -----
From: "Paolo Carlini" <pcarlini@suse.de>
To: "Bo Persson" <bop@gmb.dk>
Cc: "libstdc++" <libstdc++@gcc.gnu.org>
Sent: Wednesday, February 04, 2004 6:24 PM
Subject: Re: [RFC] On the uses of less<>() in basic_string
> Bo Persson wrote:
>
> > Why? Just just std::less<> for everything.
>
> This is a simple very good suggestion. Thanks!
>
> > No peeking! :-)
> >
> > How do you know that traits::copy uses memcpy? That is an implementation
> > detail that is specifically delegated to char_traits, so that you
> > shouldn't
> > have to care about that in basic_string. Just use it!
>
> This is something interesting (i.e., I'm not sure what the standard says
;)
>
> As far as the instantiations for char and wchar_t are concerned, as an
> implementor I'm allowed to peek, right?
Maybe. :-)
If it really matters, and you know the implementors of allocator and
char_traits well enough, you might use some inside info. The risk, of
course, is that your code might break if their implementation changes. Is it
worth the risk?
>
> As far as the instantiations for whatever != {char, wchar_t} are
concerned,
> is really a user of the library supposed to provide a less<>() consistent
> with char_traits? Can you enlighten me about that?
I don't think the standard specifies this. However, the original problem is
that we can't really tell what type allocator::pointer could be. If I
remember correctly, the original idea was to allow things like near and far
pointers, which were much used on machines like 16 bit PCs.
For segmented addresses, operator<(pointer, pointer) could get away with
comparing only the offsets if you know that the pointers point into the same
structure, and a structure is always in a single segment. On the other hand,
std::less<> might have to perform some expensive normalization (possibly
involving an OS call) to get a linear address to compare.
If you provide such an allocator, you will no doubt have to provide a
std::less<> specialization for its pointer type. Otherwise the default
fallback to operator< will work fine.
I don't know if you can write a conforming char_traits to match such an
allocator though. :-)
Bo Persson