This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]