Bug 43595 - std::unique incorrectly assumes transitive property on functor, operator==
Summary: std::unique incorrectly assumes transitive property on functor, operator==
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-31 04:29 UTC by David Krauss
Modified: 2010-03-31 09:57 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Krauss 2010-03-31 04:29:16 UTC
According to the standard ยง25.2.8, std::unique has behavior defined in terms of

   *i == *(i - 1) or pred(*i, *(i - 1)) != false

however the current implementation compares each successive element to the first in the "equal" range. This is only equivalent if the transitive property holds.

This is certainly wrong if a functor is passed, and it may be wrong for the other case as well. The non-functor version is defined to evaluate *i == *(i - 1) but does not require EqualityComparable elements.

C++0x does impose this requirement: "The comparison function shall be an equivalence relation."
Comment 1 Chris Jefferson 2010-03-31 08:09:53 UTC
Fixing this would make std::unique quite a bit less efficient. I personally believe the intention was always to make it an equivalence relation and as you say C++0x tightens up the condition.

If this had come up 5 or 6 years ago, I might have suggested fixing it, but changing it now would produce an incompatibility between our C++03 and C++0x implementations unnecessarily.

Does any other compiler get this right? If they did that would make a more convincing case, but I'm fairly sure they don't.
Comment 2 Jonathan Wakely 2010-03-31 09:57:18 UTC
This is a defect in the original standard:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202

The policy of libstdc++ is to fix defects, and I see no benefit in changing the C++03 behaviour to be incompatible with C++0x.

I'm closing this as WONTFIX rather than INVALID