Bug 67617 - [DR 2542] Non-standard const requirements imposed on associative container comparison objects
Summary: [DR 2542] Non-standard const requirements imposed on associative container co...
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.8.4
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-17 19:12 UTC by Matthew Dempsky
Modified: 2016-12-01 14:02 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2015-09-27 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Dempsky 2015-09-17 19:12:29 UTC
This code appears to me to be conforming to the C++ standard, but it's rejected by G++/libstdc++:

    #include <set>
    struct compare {
      bool operator()(int a, int b);
    };
    void func() {
      const std::set<int, compare> s;
      s.find(0);
    }

because compare::operator() is not const qualified.

N3690 [associative.reqmts]p2 says "The object of type Compare is called the comparison object of the container", and p3 talks about the requirements on behavior of a comparison object comp.  However, none of the requirements seem to impose requirements on objects of type const Compare.
Comment 1 Jonathan Wakely 2015-09-17 23:34:02 UTC
If that code is conforming then it's a defect in the standard.
Comment 2 Jonathan Wakely 2015-09-17 23:36:56 UTC
Both Clang/libc++ and MSVC/Dinkumware reject it for the same reason.
Comment 3 Daniel Krügler 2015-09-26 17:24:24 UTC
(In reply to Jonathan Wakely from comment #1)
> If that code is conforming then it's a defect in the standard.

I agree. I believe the wording for associative containers is not as clear as it should be. For unordered containers 23.2.5 p11 speaks of "possibly const value" for hasher and binary predicate, but in 23.2.4 p8 this additional "possibly const" requirement is missing. I'm submitting an LWG issue for this and provide the issue number once available.
Comment 4 Daniel Krügler 2015-09-26 18:27:22 UTC
(In reply to Jonathan Wakely from comment #2)
> Both Clang/libc++ and MSVC/Dinkumware reject it for the same reason.

I notice that the Dinkumware version associated with Visual Studio 2015 accepts the code.
Comment 5 Daniel Krügler 2015-09-26 20:18:26 UTC
(In reply to Daniel Krügler from comment #3)
> [..] I believe the wording for associative containers is not as clear as
> it should be. For unordered containers 23.2.5 p11 speaks of "possibly const
> value" for hasher and binary predicate, but in 23.2.4 p8 this additional
> "possibly const" requirement is missing. I'm submitting an LWG issue for
> this and provide the issue number once available.

Please refer to LWG issue http://cplusplus.github.io/LWG/lwg-active.html#2542
Comment 6 Daniel Krügler 2015-09-26 20:42:44 UTC
(In reply to Daniel Krügler from comment #4)
> (In reply to Jonathan Wakely from comment #2)
> > Both Clang/libc++ and MSVC/Dinkumware reject it for the same reason.
> 
> I notice that the Dinkumware version associated with Visual Studio 2015
> accepts the code.

... assuming a proper definition of the operator() overload is provided, of-course.
Comment 7 Jonathan Wakely 2016-12-01 14:02:15 UTC
The standard was clarified to confirm that what we do is correct.