public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/52917] New: explicitly stated return type in std::mem_fn cannot be compiled
@ 2012-04-09 19:51 freunddeslichts at web dot de
2012-04-09 21:18 ` [Bug libstdc++/52917] [DR 2048] " redi at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: freunddeslichts at web dot de @ 2012-04-09 19:51 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52917
Bug #: 52917
Summary: explicitly stated return type in std::mem_fn cannot be
compiled
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: freunddeslichts@web.de
#include <functional>
struct X {
int a;
int& easy() {return a;}
int& get() {return a;}
const int& get() const {return a;}
};
int main(void)
{
auto x = std::mem_fn (&X::easy); // (1) works
auto y = std::mem_fn <int&>(&X::get ); // (2) ERROR!!
auto z = std::mem_fun<int&>(&X::get ); // (3) deprecated in c++11, but works:
return 0;
}
################################################################################
(2) needs the return type to diffrentiate between the const and the non-const
getter.
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]
(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".
Both g++-4.7 and clang++-3.1 (when compiling with libstdc++) try to instantiate
the first version by mistake.
This definitely a library error, because clang when compiling with libc++
correctly instantiates the second version of mem_fn.
##################################################################################
g++-4.7 -std=c++0x bug.cpp
bug.cpp: In function ‘int main()’:
bug.cpp:17:39: error: no matching function for call to ‘mem_fn(<unresolved
overloaded function type>)’
bug.cpp:17:39: note: candidate is:
In file included from bug.cpp:3:0:
/usr/include/c++/4.7/functional:821:5: note: template<class _Tp, class _Class>
std::_Mem_fn<_Tp _Class::*> std::mem_fn(_Tp _Class::*)
/usr/include/c++/4.7/functional:821:5: note: template argument
deduction/substitution failed:
/usr/include/c++/4.7/functional: In substitution of ‘template<class _Tp, class
_Class> std::_Mem_fn<_Tp _Class::*> std::mem_fn(_Tp _Class::*) [with _Tp =
int&; _Class = <missing>]’:
bug.cpp:17:39: required from here
/usr/include/c++/4.7/functional:821:5: error: creating pointer to member
reference type ‘int&’
bug.cpp:17:39: error: unable to deduce ‘auto’ from ‘<expression error>’
####################################################################################
clang++ -std=c++0x bug.cpp
bug.cpp:17:12: error: no matching function for call to 'mem_fn'
auto y = std::mem_fn <int&>(&X::get ); // (2) ERROR!!
^~~~~~~~~~~~~~~~~~
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../include/c++/4.7/functional:820:5:
note: candidate template ignored: substitution failure [with _Tp = int &]
mem_fn(_Tp _Class::* __pm)
^
1 error generated.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/52917] [DR 2048] explicitly stated return type in std::mem_fn cannot be compiled
2012-04-09 19:51 [Bug libstdc++/52917] New: explicitly stated return type in std::mem_fn cannot be compiled freunddeslichts at web dot de
@ 2012-04-09 21:18 ` redi at gcc dot gnu.org
2012-04-09 21:35 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2012-04-09 21:18 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/52917] [DR 2048] explicitly stated return type in std::mem_fn cannot be compiled
2012-04-09 19:51 [Bug libstdc++/52917] New: explicitly stated return type in std::mem_fn cannot be compiled freunddeslichts at web dot de
2012-04-09 21:18 ` [Bug libstdc++/52917] [DR 2048] " redi at gcc dot gnu.org
@ 2012-04-09 21:35 ` redi at gcc dot gnu.org
2012-04-10 9:54 ` freunddeslichts at web dot de
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2012-04-09 21:35 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52917
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-09 21:35:07 UTC ---
(In reply to comment #1)
> Or you can do
>
> auto y = std::mem_fn((int& (X::*)())&X::get );
Or
auto y = std::mem_fn <int&()>(&X::get );
Which should also work with either libstdc++ or libc++
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/52917] [DR 2048] explicitly stated return type in std::mem_fn cannot be compiled
2012-04-09 19:51 [Bug libstdc++/52917] New: explicitly stated return type in std::mem_fn cannot be compiled freunddeslichts at web dot de
2012-04-09 21:18 ` [Bug libstdc++/52917] [DR 2048] " redi at gcc dot gnu.org
2012-04-09 21:35 ` redi at gcc dot gnu.org
@ 2012-04-10 9:54 ` freunddeslichts at web dot de
2012-04-10 11:24 ` redi at gcc dot gnu.org
2014-05-07 16:38 ` redi at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: freunddeslichts at web dot de @ 2012-04-10 9:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52917
--- Comment #3 from freunddeslichts at web dot de 2012-04-10 09:54:28 UTC ---
Ok, I didn't know about the defect report and resolution yet.
I must admit that I quite like the <int&()> syntax.
I added a remark about the defect and a short example to
http://en.cppreference.com/w/cpp/utility/functional/mem_fn
And I noted that the most c++11-ish code would be anyway:
auto y = [] (X& x) {return x.get();};
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/52917] [DR 2048] explicitly stated return type in std::mem_fn cannot be compiled
2012-04-09 19:51 [Bug libstdc++/52917] New: explicitly stated return type in std::mem_fn cannot be compiled freunddeslichts at web dot de
` (2 preceding siblings ...)
2012-04-10 9:54 ` freunddeslichts at web dot de
@ 2012-04-10 11:24 ` redi at gcc dot gnu.org
2014-05-07 16:38 ` redi at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2012-04-10 11:24 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52917
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-10 11:23:51 UTC ---
(In reply to comment #3)
> Ok, I didn't know about the defect report and resolution yet.
> I must admit that I quite like the <int&()> syntax.
It's a peculiarity of the C++ grammar, the function parameter R T::*pm is a
pointer to member, with T deduced as X and R deduced as the function type
int&()
If it helps, consider that you can declare X::get() like this:
#include <functional>
struct X
{
int a;
typedef int& func_type();
func_type get;
};
int& X::get() { return a; }
And then you can use the typedef with mem_fn:
auto pm = std::mem_fn<X::func_type>(&X::get);
> I added a remark about the defect and a short example to
> http://en.cppreference.com/w/cpp/utility/functional/mem_fn
N.B. That page has a heading "Execptions"
> And I noted that the most c++11-ish code would be anyway:
>
> auto y = [] (X& x) {return x.get();};
In most cases yes, but mem_fn has the advantage it always returns the same
type, whereas two lambda expressions produce two different closure types even
if the expressions are identical, and mem_fn might be easier to use in
late-specified return types.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/52917] [DR 2048] explicitly stated return type in std::mem_fn cannot be compiled
2012-04-09 19:51 [Bug libstdc++/52917] New: explicitly stated return type in std::mem_fn cannot be compiled freunddeslichts at web dot de
` (3 preceding siblings ...)
2012-04-10 11:24 ` redi at gcc dot gnu.org
@ 2014-05-07 16:38 ` redi at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2014-05-07 16:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52917
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|SUSPENDED |RESOLVED
Resolution|--- |INVALID
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The standard agrees with libstdc++ now, so this is invalid.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-05-07 16:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-09 19:51 [Bug libstdc++/52917] New: explicitly stated return type in std::mem_fn cannot be compiled freunddeslichts at web dot de
2012-04-09 21:18 ` [Bug libstdc++/52917] [DR 2048] " redi at gcc dot gnu.org
2012-04-09 21:35 ` redi at gcc dot gnu.org
2012-04-10 9:54 ` freunddeslichts at web dot de
2012-04-10 11:24 ` redi at gcc dot gnu.org
2014-05-07 16:38 ` redi at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).