Re: [boost] Re: Re: is_class

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2003-02-05 17:40:36

Peter Dimov wrote:

(Hi, Peter.  I'm merging two different posts on this subject and replying to
both simultaneously.)

>>> Yes, exactly. Apologies for the confusion. It is a common mistake to
>>> provide only R T::* and expect that to match all pointers to
>>> members. To get back to your earlier post,
>>>
>>> int (X::*pf) () const;
>>>
>>> is not the same as
>>>
>>> typedef int (*F) () const;
>
> Should be typedef int F() const;
>
>>> since the first typedef is ill-formed, function types cannot be
>>> cv-qualified.
>
> That's 9.3/9, and yes, you are right, the typedef is legal.

Yes an no.  The typedef is ill-formed, but not directly because of the
cv-qualification.  To be technically accurate here, you cannot form a regular
pointer (or reference) to a cv-qualified function type.  It is prohibited.  I.e.

typedef int F() const; // legal

typedef int (*F)() const; // illegal
typedef int (&F)() const; // illegal

> I learn
> something new every day. Even though 3.9.3/1 implies that functions
> cannot
> be cv-qualified, and 8.3.5/4 says that creating a cv-qualified
> function type makes the program ill-formed, R T::* still matches a
> const member function, creating a const qualified function type as R.
> Or so Comeau says. C++ sure moves in mysterious ways.

Comeau is correct here.  I'll spend a few words to clarify the subject though.
Normal cv-qualification is compounded from some other type, as in "const T."  In
the case of function types however, cv-qualification is not compounded.  It is
inherently part of the base function type or it isn't.  So, from a certain
point-of-view, the above is accurate.  You cannot take a function type and
cv-qualify it.  However, the function type itself might already be cv-qualified.
In other words, cv-qualification on functions is not normal cv-qualification.
Specifically, it refers to the cv-qualification of the implicit this pointer.
E.g. something like this pseudo code:

typedef void f() const;

...roughly equivalent (in pseudocode) to this:

typedef void f(const class* this);

...which is why certain limitations exist on cv-qualified function types.
Specifically, they can only be used in three ways:  1) to declare a non-static
member function 2) to declare the pointed-to type of a pointer-to-member, and 3)
to declare another typedef.  Note that in the first two cases (i.e. the cases of
actual use), the pseudo-type 'class' in the above can be deduced, either from
the enclosing class or from the pointer-to-member class type.  Any other use is
illegal--such as forming a regular pointer or reference to a cv-qualified
function type.  Then second case is interesting in the particular case of
detecting pointers-to-member-functions.  The following is all legal:

typedef void F() const;

struct X {
    F f;
};

void X::f() const { }

F X::* pf = &X::f;

By the same token, the function type 'F' can be extracted from a
pointer-to-member-function with the specialization "R X::*" with 'R' being the
original function type:

#include <iostream>

template<class, class> struct is_same {
    enum { value = false };
};

template<class T> struct is_same<T, T> {
    enum { value = true };
};

template<class> struct extract;
template<class R, class C> struct extract<R C::*> {
    enum { value = is_same<R, F>::value };
};

int main() {
    std::cout
        << extract<F X::*>::value // 1
        << &std::endl;
    return 0;
}

Just for the record, however, Comeau doesn't get this whole area right (and many
other compilers don't get it right at all).  Comeau doesn't consider the type
extracted from a pointer-to-member-function to be a regular function type.
Rather, it considers it to be some type of psuedo-function-type ala "member
function type"--which is incorrect.  An example demonstrates this:

#include <iostream>
#include <typeinfo>

typedef void F();

struct X { };

typedef F X::* PMF;

template<class> struct extract;
template<class R, class C> struct extract<R C::*> {
    typedef R type;
};

extract<PMF>::type f; // decl:  no error

void f() { return; } // def:  error

int main() {
    std::cout
        << typeid(f).name() // compiler crash
                            // i.e. not an ICE
        << &std::endl;
    return 0;
}

I've been talking about this issue with Daveed Vandevoorde for the last couple
weeks, so EDG is aware of the issue.

Paul Mensonides