In article <JASON.94Sep30110257@phishhead.cygnus.com> jason@cygnus.com writes:
>>>>>> Information Processing Ltd <ipl@iplbath.demon.co.uk> writes:
>> class CLASS
>>      {
>>      int foo();
>>      };
>>
>> int CLASS::TYPEDEF();
>I assume you mean 'typedef int CLASS::TYPEDEF ();' here.
Yes, sorry.

>
>> TYPEDEF *pfn = CLASS::foo;
>
>> It would appear that the :: and * part of the ::* operator are being
>> separated. Is this what is intended?
>
>::* is not an operator.  But that does appear to be what is intended.

What exactly does one call it, BTW? Is it just 'a token', or is there
some proper terminology. Is it 'a token' or is it two tokens?

>
>But in neither document are typedefs mentioned.  Thus, the code you quote
>is ill-formed, because the declarator-id in the typedef is
>'CLASS::TYPEDEF'.
>
>Jason
>
Does anyone have any feel for the level of support for this construct in
current compilers? Please try it out and mail me. I would assume from
Jason's comments that GCC doesn't support it.
cfront based compilers *do* seem to support it.

Is it likely for a change like supporting this code to be introduced into
the 'standard' at this stage?

Thanks for your help

>>>>> Information Processing Ltd <ipl@iplbath.demon.co.uk> writes:

>> ::* is not an operator.  But that does appear to be what is intended.

> What exactly does one call it, BTW? Is it just 'a token', or is there
> some proper terminology. Is it 'a token' or is it two tokens?

It is two tokens.  In the grammar, it is an expansion of the non-terminal
"ptr-operator":

ptr-operator:
 * cv-qualifier-seqopt
        &
        ::opt nested-name-specifier * cv-qualifier-seqopt

>> But in neither document are typedefs mentioned.  Thus, the code you quote
>> is ill-formed, because the declarator-id in the typedef is
>> 'CLASS::TYPEDEF'.

> Does anyone have any feel for the level of support for this construct in
> current compilers? Please try it out and mail me. I would assume from
> Jason's comments that GCC doesn't support it.  cfront based compilers
> *do* seem to support it.

g++ has historically had half-hearted support for it.  I have been disabling
that support.

> Is it likely for a change like supporting this code to be introduced into
> the 'standard' at this stage?

Doubtful.  Such a change would mean a significant change in the type
system, introducing the concept of member type.  While this may be
desirable (I'm sure John desires it), I don't think it is likely to happen.

It would also mean that declarator-id's are parsed differently for typedefs
than for other declarations, which is a non-orthogonality I think we can do
without.

Jason

>>>>> Information Processing Ltd <ipl@iplbath.demon.co.uk> writes:

> class CLASS
>         {
>         int foo();
>         };

> int CLASS::TYPEDEF();

I assume you mean 'typedef int CLASS::TYPEDEF ();' here.

> TYPEDEF *pfn = CLASS::foo;

> It would appear that the :: and * part of the ::* operator are being
> separated. Is this what is intended?

::* is not an operator.  But that does appear to be what is intended.

> Most importantly, is this valid in

>         i) the ARM (please quote references)
>         ii) ISO C++ (assuming this level of detail won't change)

No, and no.  ARM 8.2:

  Except for the declarations of some special functions (12.2, 13.4) a dname
  will be a simple identifier.

Of course, this rule prohibits defining members outside of the class body.
The current Working Paper fixes that:

            A  declara-
  tor-id  shall  be a simple identifier, except for the following cases:
  the declaration of some special functions (_class.conv_, _class.dtor_,
  _over.oper_),  the definition of a member function (_class.mfct_), the
  definition of a static data member (_class.static_),  the  declaration
  of   a   friend   function   that   is   a  member  of  another  class
  (_class.friend_).

But in neither document are typedefs mentioned.  Thus, the code you quote
is ill-formed, because the declarator-id in the typedef is
'CLASS::TYPEDEF'.

Jason

Hi

The following code (or something similar) appears in an SGI lib++ header.

class CLASS
        {
        int foo();
        };

int CLASS::TYPEDEF();

TYPEDEF *pfn = CLASS::foo;


It would appear that the :: and * part of the ::* operator are being
separated. Is this what is intended?

Most importantly, is this valid in

        i) the ARM (please quote references)
        ii) ISO C++ (assuming this level of detail won't change)

Thanks for your help

Misha Dorman
(post replies here, or mail to mishad@iplbath.demon.co.uk)