Movatterモバイル変換


[0]ホーム

URL:


This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2025-12-20


162. (&C::f)() with nonstatic members

Section:12.2.2.2  [over.match.call]    Status:CD1    Submitter:Steve Adamczyk    Date:26 Aug 1999

[Moved to DR at October 2002 meeting.]

12.2.2.2 [over.match.call] paragraph 3says that when a call of the form

   (&C::f)()
is written, the set of overloaded functions named byC::fmust not containany nonstatic member functions. A footnote gives the rationale: if a memberofC::f is a nonstatic member function,&C::f is a pointer to memberconstant, and therefore the call is invalid.

This is clear, it's implementable, and it doesn't directly contradictanything else in the standard. However, I'm not sure it's consistentwith some similar cases.

In 12.3 [over.over] paragraph 5,second example, it is made amply clear that when&C::f isused as the address of a function, e.g.,

   int (*pf)(int) = &C::f;
the overload set can contain both static and nonstatic member functions.The function with the matching signature is selected, and if it isnonstatic&C::fis a pointer to member function, and otherwise&C::f isa normal pointer to function.

Similarly, 12.2.2.2.2 [over.call.func]paragraph 3 makes it clear that

   C::f();
is a valid call even if the overload set contains both static andnonstatic member functions. Overload resolution is done, and if anonstatic member function is selected, an implicitthis-> is added,if that is possible.

Those paragraphs seem to suggest the general rule that you do overloadresolution first and then you interpret the construct you haveaccording to the function selected. The fact that there are staticand nonstatic functions in the overload set is irrelevant; it's onlynecessary that the chosen function be static or nonstatic to matchthe context.

Given that, I think it would be more consistent if the(&C::f)() casewould also do overload resolution first. If a nonstatic member ischosen, the program would be ill-formed.

Proposed resolution (04/01):

  1. Change the indicated text in 12.2.2.2 [over.match.call] paragraph 3:

    The fourth case arises from apostfix-expression of the form&F, whereF names a set of overloaded functions.In the context of a function call,the set of functions named byF shall contain only non-memberfunctions and static member functions. [Footnote:IfF names a non-static member function,&Fis a pointer-to-member, which cannot be used with the function call syntax.]And in this context using&F behaves the same as using&F is treated the same asthe nameF by itself.Thus,(&F)(expression-listopt)is simply(F)(expression-listopt), which isdiscussed in 12.2.2.2.2 [over.call.func].If the function selected by overload resolution according to12.2.2.2.2 [over.call.func] isa nonstatic member function, the program isill-formed. [Footnote: WhenF is a nonstatic memberfunction, a reference of the form&A::F is apointer-to-member,which cannot be used with the function-call syntax, anda reference of the form&F is an invalid use of the"&" operator on a nonstatic member function.](The resolution of&F in other contexts is described in12.3 [over.over].)



[8]ページ先頭

©2009-2026 Movatter.jp