Anton Pevtsov wrote:
[...]
Martin Sebor wrote:
I don't think it's incorrect since compare() must be implemented as if
by calling eq(), although the standard should probably not mandate > one
or the other. The way it's done in our implementation, however, is
probably going to be extremely inefficient. There are much better >
algorithms than this naive method. We need an issue for the efficiency
side of things at the very least (I suspect the efficient algorithm >
will end up using eq() directly).
I found that our compare implementation uses memcmp and doesn't call
eq().
Maybe it will be useful to open a jira issue about that?
The use of memcmp() is okay for std::string (and wmemcmp() for
std::wstring) since it's not detectable by a conforming program
what those specializations of basic_string use "under the hood."
All other specializations of basic_string must behave as specified
since their behavior is detectable (e.g., by supplying a user
defined traits class).
So I agree that we should probably have an issue tracking the
fact that our compare() fails to use traits::eq(), even though
it's IMO a QoI issue whether we use it or traits::compare().
Martin
