Since quite a few people have brought up fvali's post ( cf.
http://www.deja.com/=rj/[ST_rn=ap]/getdoc.xp?AN=451759382
) from March 5 responding to Andrei's question about how to determine
whether a class argument of a template has a certain member, I thought I
would take a look at it.  fvali came up with an absolutely brilliant, fully
standard conformant way of coming very close to doing this.  The exact code
that fvali posted won't compile because he has an illegal definition that
appears to be left over from an earlier implementation.  Also, once fixed,
it can only determine whether a class has a specified inner type.  It's
unable to handle member data or member functions.

His code is definitely hard to understand and it's a little more
complicated than it needs to be.  Here's a simpler re-implementation of his
idea:

class unique {};
template<class _Typ, class _Uq = unique >
class key_type_tester : private _Typ
{
        struct nested;
        friend struct nested;
        typedef char (& yes)[1];
        typedef char (& no)[2];
        static no test(_Uq);
        static yes test(...);

5 In the definition of a member of a class template that appears outside
of  the  class  template definition, the name of a member of this tem-
plate hides the name of a template-parameter.  [Example:
          template<class T> struct A {
                  struct B { /* ... */ };
                  void f();
          };

          template<class B> void A<B>::f()
          {
                  B b;  // A's B, not the template parameter
          }
  --end example]

Because the definition of nested occurs outside the class template
definition, any members of the key_type_tester template (which, crucially,
includes all of _Typ's members) which have the name key_type, hide the
template parameter named key_type.  So, in the expression test(key_type()),
it is either unique's constructor being referenced, or an inner type of
_Typ named key_type if one exists.  Since test() is overloaded, one version
accepting unique objects and the other accepting anything else, if _Typ
doesn't have a key_type, "static no test(_Uq)" is referenced, otherwise
"static yes test(...)" is.  Since these two functions return different
sized types, sizeof lets us determine which is actually referenced.

There are (at least) 2 cases where this code will produce compile time
errors:

1.  There is a non-type, non-static member of _Typ named key_type.
2.  There is no default constructor for _Typ's key_type.
3.  There is an inaccessible (private) member of _Typ named key_type.

As far as I can tell (1) is unavoidable.  (2) can be fixed by making
sizeof(unique) effectively unique (e.g. class unique {char u[5431];};) and
then modifying the enum to:
enum { has_key_type= sizeof(key_type) != sizeof(unique) };

The rest of the template apparatus that fvali uses achieves 2 things that
are different than my implementation:

1.  The unique class is a private member of the key_type_tester template.
2.  references to the compile time constant do not need the "nested" scope
modifier.

All of this is helpful, but what is really needed is a way to determine
whether a type has a certain member.  I worked out a way to do this for
member functions, but I now have this horrible suspicion that it is not
standard conformant.  Anyway, here it is since I've already put it together
:-).  

There are two ways to do it.  You can either test for a member function
with a certain name having any signature or for one having a specific
signature.  The following tests code test for the first case:

class A {
public:
        int memfun();

template<class _Typ, int dummy = 1 >
class memfun_tester : private _Typ
{
        struct nested;
        friend struct nested;
        typedef char (& yes)[1];
        typedef char (& no)[2];
        static no test(...);
        static yes test(int (_Typ::*)());

This code works on the Intel Compiler 4.0 (which uses the EDG front-end),
but as I mentioned, I don't think it conforms to the standard.  It depends
on "memfun" referring to a pointer to a member function.  However, the
standard says in 5.3.1p3, "A pointer to a member is only formed when an
explicit & is used and its operand is a qualified-id not enclosed in
parentheses."  This sounds pretty unequivocal :(.  Many compilers, it
seems, do not conform on this point, but, obviously, that's not something
that can be trusted.  If it doesn't work then this name hiding technique
cannot be used to determine whether a class has certain member functions.
I think that I can actually prove this, but I'm tired of typing at the
moment :).  (Note that the type member test still works - except in the odd
cases I've mentioned).

Hope this helps -- and if anyone has any ideas, please post them.

John Madsen

jmadsen at rci dot rutgers dot edu

[snip]

template<class _Typ, class _Uq = int>
class key_type_tester : private _Typ
{
    struct nested;
    friend struct nested;
    typedef char (& yes)[1];
    typedef char (& no)[2];
    static no test(int*);
    static yes test(...);

The code became a bit even easier to understand. I think this is a
breakthrough in what one can do with C++. It brings a bit of
introspection at compile time possible, which wasn't even considered
possible until now. I also think that techniques based upon
overloading, sizeof, and char[1] and char[2] are going to become
common in the next century (ahem). They have a lot of uses you
wouldn't think of.

Ok, now we've got the ability to find out whether an arbitrary class
has a member type of a given name. What are we going to do with
this?... :o)

Andrei

John Madsen

jmadsen at rci dot rutgers dot edu

I'm still hoping for a response to my posting, but at this point the
correctness of my code has not been resolved.  If it is in fact
correct, then it could be used to get much the same effect as your
code.  In particular, you could write a global template function with
some default behavior, then optionally "override" it with a member
template providing "specialized" behavior which propagates to derived
classes.  You could also compare typeof(foo<T>) with typeof(::foo<T>)
and use the boolean result to drive partial specializations.

Anyway, I made a few additions to your code so I could compile and test
it:

#include <iostream>
using namespace std;

class A {
public:
        int memfun();

template<class _Typ, int dummy = 1 >
class memfun_tester : private _Typ
{
        struct nested;
        friend struct nested;
        typedef char (& yes)[1];
        typedef char (& no)[2];
        static no test(int);
        static yes test(...);

OTOH, on gcc 2.95, the output was
0
0

MSVC 6 wouldn't compile it at all (no surprise there).  Neither would
Metrowerks CW 5.0.  Here's the output from Metrowerks:

### MWCC.EXE Compiler:
#    File: unqualptrtomember.cpp
# ------------------------------
#      23:  struct memfun_tester<_Typ, memfun >::nested {
#   Error:                                              ^
#   struct/union/enum/class tag 'memfun_tester' redefined
### MWCC.EXE Compiler:
#      24:   enum { has_memfun = sizeof(test(memfun)) != sizeof(no) };
#   Error:                                         ^
#   undefined identifier 'test'
### MWCC.EXE Compiler:
#      25:  };
#   Error:   ^
#   illegal template declaration
### MWCC.EXE Compiler:
#      28:   cout << memfun_tester<A>::nested::has_memfun << endl;
#   Error:                                     ^^^^^^^^^^
#   undefined identifier 'memfun_tester<A, 1>::nested::has_memfun'
### MWCC.EXE Compiler:
#      29:   cout << memfun_tester<B>::nested::has_memfun << endl;
#   Error:                                     ^^^^^^^^^^
#   undefined identifier 'memfun_tester<B, 1>::nested::has_memfun'

Since only one of the four compilers successfully processed your code
and produced the desired answer, this tends to confirm that your
interpretation of 5.3.1p3 is correct and that there is no loophole by
which a pointer to member may be formed from an unqualified name.

--
Regards,
Ivan J. Johnson
Sacramento, CA

Sent via Deja.com http://www.deja.com/
Before you buy.

The error (or at least warning) that I would expect based on 5.3.1p3 would
occur here:

template< class _Typ, int memfun >
struct memfun_tester<_Typ, memfun >::nested {
        enum { has_memfun = sizeof(test(memfun)) != sizeof(no) };
                                    ^^^^^^
when the template is instantiated with _Typ equal to a type that has a
public or protected member function named memfun.  The error should be
something like that it cannot convert "memfun" to a pointer to a member
function or that it is an invalid use memfun in some way.  I have yet to
find a compiler that actually gives such an error or warning.

gcc's behavior suggests not that there is no loophole or that my
interpretation of 5.3.1p3 is wrong, but that it doesn't conform to 14.6.1p5
which is the paragraph fvali pointed out that got all of this started :).

John Madsen

jmadsen at rci dot rutgers dot edu

template < class A, class B >
class DeriveWithBuffer: public A
  {
   private:
      unsigned char buffer[ sizeof(B) ];

      void ZeroBuffer()
        {
         memset( buffer, 0, sizeof(B) );
        }
   [...]
  };

Everything here works as expected.  But if the definition of ZeroBuffer
is moved outside the class:

template < class A, class B >
void DeriveWithBuffer<A,B>::ZeroBuffer()
  {
   memset( buffer, 0, sizeof(B) );
  }

Here B may refer to a type nested in A, rather than the template parameter.
That change seems dangerous to me.

                                                --Lisa Lippincott

Yes, I agree that the "feature" described in 14.6.1p5 can have odd, and
except in this introspection case, unwanted effects.  I can't figure out
why this in the standard unless, although I think this is very unlikely, it
was to allow something like what fvali has proposed.  I would love to hear
from anyone who knows what it's doing there.

John Madsen

jmadsen at rci dot rutgers dot edu

...\unqualptrtomember.cpp(28) : error C2027: use of undefined type
'nested'
...\unqualptrtomember.cpp(14) : see declaration of 'nested'
...\unqualptrtomember.cpp(28) : error C2065: 'has_memfun' : undeclared
identifier
...\unqualptrtomember.cpp(29) : error C2027: use of undefined type
'nested'
...\unqualptrtomember.cpp(14) : see declaration of 'nested'

So, no conclusion can be drawn from the fact that Metrowerks and MS
rejected the code.

If the base memfun is not allowed to hide the template parameter
memfun, then gcc would be correct in accepting the code above, in
always assuming that 'memfun' refers to the template parameter, and in
producing the output it produces.  In other words, the fact that it
doesn't report an error does not imply that it is actually taking the
address of a member as you want.

--
Regards,
Ivan J. Johnson
Sacramento, CA

Sent via Deja.com http://www.deja.com/
Before you buy.

Here is my reasoning (which I hope is flawed ;-)) -
14.6.2.1 says -
[temp.dep.type]
14.6.2.1 Dependent types
1 A type is dependent if it is
— a template parameter,
— a qualified­id with a nested­name­specifier which contains a
class­name that names a dependent type or
whose unqualified­id names a dependent type,
— a cv­qualified type where the cv­unqualified type is dependent,
— a compound type constructed from any dependent type,
— an array type constructed from any dependent type or whose size is
specified by a constant expression
that is value­dependent,
— a template­id in which either the template name is a template
parameter or any of the template argu­ments
is a dependent type or an expression that is type­dependent or
value­dependent.

The only way key_type will be unbound and looked up at the point of the
template instantiation (14.6.4.1) in both the context of the template
definition and the context of the point of instantiation is if
'key_type' is considered a template parameter, right?

If its lookup is not posponed then it must be bound in the definition
context, right? Which means it would have to be an error if not found in
the definition context - without any instantiation of templates.

If 'key_type' is considered a template parameter and its lookup is
postponed till the point of instantiation, it seems 'screwed up' (sorry
for getting all technical) that upon look up at the point of
instantiation 'key_type' will not be considered a template parameter and
will now be bound to a member of a base class of our instantiated
template class.

Also, keep in mind that 14.6.1p5 is in a section that discusses locally
declared names within templates.

Therefore :
template<class T> struct S
{
   struct A; // locally declares A

struct I
{
   struct A;  // Note: not declared in a template

In S<I> can 'A' be considered a locally declared name?

Anyway I find this all fairly unclear.  What do you folks think of all
this?

I hoped some of the C++ gurus would post a definitive answer resolving
this issue, or someone would log a defect report - but if this has been
done, I have missed it.

regards,
-fais