In article <rfgCH85x3.Hs@netcom.com>,
Ronald F. Guilmette <rfg@netcom.com> wrote:
>>The term "function" includes member functions.
>
>Jamshid, I do not share your view in this case.
>
>In general, it appears to me that both the ARM and current X3J16 working
>paper are very explicit in specifying whether any given rule applies to
>either "functions" or "member functions".  I do not think that the latter
>is considered a subset of the former.  Rather, the ARM and the X3J16 WP
>seem (in general) to treat these as two entirely disjoint sets.

Can you provide examples where the ARM/WP treat functions and member
functions as disjoint sets?  I see a lot of wording like 7.1.2's
"[inline and virtual] can be used only in function declarations" and
"for a nonmember function an inline specifier also gives ...".  If
"member functions" were not "functions", the use of "nonmember" would
be redundant.  Also in 7.1.2: "A function defined within the
declaration of a class is inline by default."  3.2 speaks only of
"function" scope, not "function and member function scope".

I don't see how you can interpret this as my "view".  I don't know
what else to say other than to repeat the quotes from my previous
article:

>>The term "function" includes member functions.  9.3: "A function
>>declared as a member ... is called a member function."  Furthermore,
>>constructors and destructors are just special kinds of member
>>functions.
>>ARM 8.2.5 Functions: "The standard header <stdarg.h> contains a
>>mechanism for accessing arguments passed using the ellipsis."  8.2.5's
>>discussion of functions includes member functions.  For example, "A
>>cv-qualifier-list can be part of a declaration or definition of a
>>nonstatic member function...".

Jamshid Afshar
jamshid@ses.com

In article <CHFBxp.5M4@ses.com> jamshid@castro.uucp (Jamshid Afshar) writes:
>In article <rfgCH85x3.Hs@netcom.com>,
>Ronald F. Guilmette <rfg@netcom.com> wrote:
>>>The term "function" includes member functions.
>>
>>Jamshid, I do not share your view in this case.
>>
>>In general, it appears to me that both the ARM and current X3J16 working
>>paper are very explicit in specifying whether any given rule applies to
>>either "functions" or "member functions".  I do not think that the latter
>>is considered a subset of the former.  Rather, the ARM and the X3J16 WP
>>seem (in general) to treat these as two entirely disjoint sets.
>
>Can you provide examples where the ARM/WP treat functions and member
>functions as disjoint sets?

Yes.

See section 4.6 (Pointer Conversions) and then look at section 4.8
(Pointer to Members).

See section 5.2.2 (Function Calls).

See sections 14.4 (Function Templates) and also 14.6 (Member Function
Templates).

The final piece of evidence I'll provide today is section 5.9 (Relational
comparisons) of the 09/28/93 X3J16 working paper wherein it is made quite
plain that pointers to functions may be (relationally) compared whereas
pointers to member functions may not be.  (This point may not be apparent
however until one reads the following section (5.10; Equality comparisons)
wherein it is made apparent that equality comparisons *may* be performed
between two compatible pointers to member functions.

>I see a lot of wording like 7.1.2's
>"[inline and virtual] can be used only in function declarations"...

Yes.  Quite so.

>I don't see how you can interpret this as my "view".  I don't know
>what else to say other than to repeat the quotes from my previous
>article:
>
>>>The term "function" includes member functions.  9.3: "A function
>>>declared as a member ... is called a member function."

I agree completely that this statement, along with several others, add
credence to the notion that member functions should be considered to be
a subset of "functions" rather than as an entirely disjoint set.  I would
say however that the wording in the sections of the ARM/WP that I have
mentioned above lead one to the opposite view.

In short, both the ARM and the WP appear to be internally inconsistant
with respect to the use of the terms "function" and "member function".
We can only hope that such inconsistancies will be rectified in the final
standard.

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <CHFBxp.5M4@ses.com> jamshid@castro.uucp (Jamshid Afshar) writes:
>In article <rfgCH85x3.Hs@netcom.com>,
>Ronald F. Guilmette <rfg@netcom.com> wrote:
>>>The term "function" includes member functions.
>>
>>Jamshid, I do not share your view in this case.
>>
>>In general, it appears to me that both the ARM and current X3J16 working
>>paper are very explicit in specifying whether any given rule applies to
>>either "functions" or "member functions".  I do not think that the latter
>>is considered a subset of the former.  Rather, the ARM and the X3J16 WP
>>seem (in general) to treat these as two entirely disjoint sets.
>
>Can you provide examples where the ARM/WP treat functions and member
>functions as disjoint sets?

 Oh, come on. Taking the address of a global function
yields a function pointer, taking the address of a non-static
member function yields a pointer to member, and THEY are completely
and categorically distinct in the ARM.

 Its quite clear to me that there are two distinct types
of functions: global functions and member functions.

I'm told the committee decided that a member function was a
function.

Its possible to decide that a member function is not like an
ordinary function, at least until its given an extra argument
(for the this pointer).

It was possible to decide that a member function is like an
ordinary function in that in context it is callable just the
same way.

However, the committee DID make a decision that distinguishes
ordinary functions from members even more strongly, namely
to all const qualified returns to control overloading
of member functions BUT NOT ORDINARY ONES.

 class X {
  void operator[](int); // #1
  void operator[](int)const; // #2
 };
 class Y {
  friend void operator[](Y&, int); // #3
  friend void operator[](Y const&, int); // #4
 };

 X x();
 const X cx();
 Y y();
 const Y cy();

 x()[1]; // calls #1, nonconst version
 cx()[1]; // calls #2, const version

 y()[1]; // calls #4, const version
 cy()[1]; // calls #4, const version

I find this distinction disturbing.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA