http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52917
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed| |2012-04-09
Summary|explicitly stated return |[DR 2048] explicitly stated
|type in std::mem_fn cannot |return type in std::mem_fn
|be compiled |cannot be compiled
Ever Confirmed|0 |1
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-09
21:18:11 UTC ---
(In reply to comment #0)
> (2) needs the return type to diffrentiate between the const and the non-const
> getter.
Or you can do
auto y = std::mem_fn((int& (X::*)())&X::get );
Which also works in this case where specifying the return type doesn't help:
struct X {
int get() { return 0; }
int get() const { return 1; }
};
> The specification for mem_fn is
>
> template< class R, class T > /*unspecified*/ mem_fn(R T::* pm);
> template< class R, class T, class... Args > /*unspecified*/ mem_fn(R (T::*
> pm)(Args...));
> [ ... some more overloads for const, volatile and references]
Maybe not for long: http://cplusplus.github.com/LWG/lwg-active.html#2048
The libstdc++ implementation exactly matches that issue's proposed resolution,
which has been voted Tentatively Ready.
> (2) should result in an instantiation of the second version with
> sizeof...(Args)==0, because argument to the first version is a "pointer to
> member data", not "pointer to member function".
No, it's a pointer to member, which can match either a pointer to member data
or pointer to member function.
If the second overload exists (as it presumably does in libc++) then it's a
better match than the first overload, but the first overload is still viable.
> Both g++-4.7 and clang++-3.1 (when compiling with libstdc++) try to
> instantiate
> the first version by mistake.
Not by mistake, by design, that overload can match any pointer to member.
I'm suspending this because I believe the resolution to DR 2048 would make
libstdc++ correct.
