Pointers to member function templates as template arguments

Hi, Consider the following code: template<typename T, void (T::*) (int)> struct MemFn; struct Foo { template<typename Int> void bar(Int) { } }; typedef MemFn<Foo, &Foo::bar> type; This compiles with VC7.1, GCC 3.4, Intel 8.0 and Comeau 4.3.3 in strict mode, but CodeWarrior 9.4 fails with the message: Error : illegal implicit member pointer conversion example.cpp line 9 typedef MemFn<Foo, &Foo::bar> type; Looking at 14.3.2/1, I notice while the third bullet, on function pointers, explicitly mentions templates, the fourth bullet, on pointers to members, doesn't. But perhaps pointers to function templates are covered implicitly. Looking at 14.3.2/5, bullet 6, I see that no conversions are applied to pointers to members. But no conversions are needed in the above example. What's needed is overload resolution, which is explicitly allowed. So who's right -- Metrowerks or everyone else? Jonathan

Jonathan Turkanis wrote: <snip> Sorry for the OT post. I thought I was sending this to comp.lang.c++.moderated. Jonathan

On Jun 1, 2005, at 6:31 PM, Jonathan Turkanis wrote:
Hi,
Consider the following code:
template<typename T, void (T::*) (int)> struct MemFn;
struct Foo { template<typename Int> void bar(Int) { } };
typedef MemFn<Foo, &Foo::bar> type;
This compiles with VC7.1, GCC 3.4, Intel 8.0 and Comeau 4.3.3 in strict mode, but CodeWarrior 9.4 fails with the message:
Error : illegal implicit member pointer conversion example.cpp line 9 typedef MemFn<Foo, &Foo::bar> type;
Looking at 14.3.2/1, I notice while the third bullet, on function pointers, explicitly mentions templates, the fourth bullet, on pointers to members, doesn't. But perhaps pointers to function templates are covered implicitly.
Looking at 14.3.2/5, bullet 6, I see that no conversions are applied to pointers to members. But no conversions are needed in the above example. What's needed is overload resolution, which is explicitly allowed.
So who's right -- Metrowerks or everyone else?
I believe everyone else is. This snippet compiles on a more recent internal compiler. I looked around for a workaround, but haven't come up with one yet. -Howard

Howard Hinnant wrote:
On Jun 1, 2005, at 6:31 PM, Jonathan Turkanis wrote:
So who's right -- Metrowerks or everyone else?
I believe everyone else is. This snippet compiles on a more recent internal compiler.
I looked around for a workaround, but haven't come up with one yet.
Thanks, Howard. I've found a workaround for my current application: using finite state machines as filters. Can I conclude from your statement about the internal compiler that the problem also exists in CodeWarrior 9.5, so that I should use TESTED_AT(0x3206) to guard my workaround?
-Howard
Jonathan

On Jun 1, 2005, at 9:28 PM, Jonathan Turkanis wrote:
Howard Hinnant wrote:
On Jun 1, 2005, at 6:31 PM, Jonathan Turkanis wrote:
So who's right -- Metrowerks or everyone else?
I believe everyone else is. This snippet compiles on a more recent internal compiler.
I looked around for a workaround, but haven't come up with one yet.
Thanks, Howard.
I've found a workaround for my current application: using finite state machines as filters. Can I conclude from your statement about the internal compiler that the problem also exists in CodeWarrior 9.5, so that I should use TESTED_AT(0x3206) to guard my workaround?
I haven't specifically tested CW 9.5. But my best guess is that this won't be corrected until __MWERKS__ >= 0x4000. -Howard

Howard Hinnant wrote:
I've found a workaround for my current application: using finite state machines as filters. Can I conclude from your statement about the internal compiler that the problem also exists in CodeWarrior 9.5, so that I should use TESTED_AT(0x3206) to guard my workaround?
I haven't specifically tested CW 9.5. But my best guess is that this won't be corrected until __MWERKS__ >= 0x4000.
I got my answer this morning from the regression reports: CW 9.5 needs the workaround too. Thanks again.
-Howard
Jonathan
participants (2)
-
Howard Hinnant
-
Jonathan Turkanis