Re: [RFC] On the uses of less<>() in basic_string

["Bo Persson" <bop at gmb dot dk>]

----- Original Message ----- 
From: "Paolo Carlini" <pcarlini@suse.de>
To: "libstdc++" <libstdc++@gcc.gnu.org>
Cc: "Nathan Myers" <ncm@cantrip.org>; "Gabriel Dos Reis"
<gdr@integrable-solutions.net>
Sent: Wednesday, February 04, 2004 5:42 PM
Subject: [RFC] On the uses of less<>() in basic_string


> Hi Nathan, hi everyone,
>
> I'm going again through the uses of those function objects in
> basic_string.
>
> At the time, Nathan (I seem to remember) suggested that because
> of portability issues wrt comparing pointers not pointing both
> inside the same _Rep.
>
> Now I'm not really convinced anymore, however. I'm under the
> impression that those uses artificially block some simplifications
> since the code has to distinguish the case of pointers pointing
> both inside the same _Rep (which can be compared with '<') and the
> case of pointers not pointing inside the same _Rep.

Why? Just just std::less<> for everything.

If it is possible to use operator<, it will of course do just that!

>
> I'm not convinced because we are seemingly so careful but then,
> when we have to actuall copy data around (from anywhere to the
> _Rep, for instance) we end up using plain traits::copy and move,
> that is, plain memcpy and memmove, eventually...

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!

>
> So, what's that really about? How are we supposed to move 'safely'
> data around in a way consistent with the function objects?

The char_traits will take care of the moving, the std::less<> will take care
of comparing pointers. What is the problem, really?  :-)



Bo Persson