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

2024-12-19

452. Wording nit on description of this

[Voted into WP at July, 2007 meeting.]

_N4868_.11.4.3.2 [class.this] paragraph 1, which specifies the meaning of the keyword 'this', seems to limit its usage to the *body* of non-static member functions. However 'this' is also usable in ctor-initializers which, according to the grammar in 9.5 [dcl.fct.def] par. 1, are not part of the body.

Proposed resolution: Changing the first part of _N4868_.11.4.3.2 [class.this] par. 1 to:

In the body of a nonstatic (9.3) member function or in a ctor-initializer (12.6.2), the keyword this is a non-lvalue expression whose value is the address of the object for which the function is called.

NOTE: I'm talking of constructors as functions that are "called"; there have been discussions on c.l.c++.m as to whether constructors are "functions" and to whether this terminology is correct or not; I think it is both intuitive and in agreement with the standard wording.

Steve Adamczyk: See also issue 397, which is defining a new syntax term for the body of a function including the ctor-initializers.

Notes from the March 2004 meeting:

This will be resolved when issue 397 is resolved.

Proposed resolution (October, 2005):

1. Change 9.5 [dcl.fct.def] paragraph 1 as indicated:

Function definitions have the form

function-definition:
decl-specifier-seq_opt declarator ctor-initializer_opt function-body
decl-specifier-seq_opt declarator function-try-block
function-body:
ctor-initializer_opt compound-statement
function-try-block

An informal reference to the body of a function should be interpreted as a reference to the nonterminal function-body.

2. Change the definition of function-try-block in Clause 14 [except] paragraph 1:

function-try-block:
try ctor-initializer_opt function-body compound-statement handler-seq

3. Change 6.4.7 [basic.scope.class] paragraph 1, point 1, as indicated:

The potential scope of a name declared in a class consists not only of the declarative region following the name's point of declaration, but also of all function bodies, bodies and default arguments, and constructor ctor-initializers in that class (including such things in nested classes).

4. Change 6.4.7 [basic.scope.class] paragraph 1, point 5, as indicated:

The potential scope of a declaration that extends to or past the end of a class definition also extends to the regions defined by its member definitions, even if the members are defined lexically outside the class (this includes static data member definitions, nested class definitions, member function definitions (including the member function body and, for constructor functions (11.4.5 [class.ctor]), the ctor-initializer (11.9.3 [class.base.init])) and any portion of the declarator part of such definitions which follows the identifier, including a parameter-declaration-clause and any default arguments (9.3.4.7 [dcl.fct.default]). [Example:...

5. Change footnote 32 in 6.5.3 [basic.lookup.unqual] paragraph 8 as indicated:

That is, an unqualified name that occurs, for instance, in a type or default argument expression in the parameter-declaration-clause, parameter-declaration-clause or in the function body, or in an expression of a mem-initializer in a constructor definition.

6. Change _N4567_.5.1.1 [expr.prim.general] paragraph 3 as indicated:

...The keyword this shall be used only inside a non-static class member function body (11.4.2 [class.mfct]) or in a constructor mem-initializer (11.9.3 [class.base.init])...

7. Change 11.4 [class.mem] paragraph 2 as indicated:

...Within the class member-specification, the class is regarded as complete within function bodies, default arguments, and exception-specifications, and constructor ctor-initializers (including such things in nested classes)...

8. Change 11.4 [class.mem] paragraph 9 as indicated:

Each occurrence in an expression of the name of a non-static data member or non-static member function of a class shall be expressed as a class member access (7.6.1.5 [expr.ref]), except when it appears in the formation of a pointer to member (7.6.2.2 [expr.unary.op]), or or when it appears in the body of a non-static member function of its class or of a class derived from its class (11.4.3 [class.mfct.non.static]), or when it appears in a mem-initializer for a constructor for its class or for a class derived from its class (11.9.3 [class.base.init]).

9. Change the note in 11.4.2 [class.mfct] paragraph 5 as indicated:

[Note: a name used in a member function definition (that is, in the parameter-declaration-clause including the default arguments (9.3.4.7 [dcl.fct.default]), or or in the member function body, or, for a constructor function (11.4.5 [class.ctor]), in a mem-initializer expression (11.9.3 [class.base.init])) is looked up as described in 6.5 [basic.lookup]. —end note]

10. Change 11.4.3 [class.mfct.non.static] paragraph 1 as indicated:

...A non-static member function may also be called directly using the function call syntax (7.6.1.3 [expr.call], 12.2.2.2 [over.match.call]) from within the body of a member function of its class or of a class derived from its class.

• from within the body of a member function of its class or of a class derived from its class, or
• from a mem-initializer (11.9.3 [class.base.init]) for a constructor for its class or for a class derived from its class.

11. Change 11.4.3 [class.mfct.non.static] paragraph 3 as indicated:

When an id-expression (_N4567_.5.1.1 [expr.prim.general]) that is not part of a class member access syntax (7.6.1.5 [expr.ref]) and not used to form a pointer to member (7.6.2.2 [expr.unary.op]) is used in the body of a non-static member function of class X or used in the mem-initializer for a constructor of class X, if name lookup (6.5.3 [basic.lookup.unqual]) resolves the name in the id-expression to a non-static non-type member of class X or of a base class of X, the id-expression is transformed into a class member access expression (7.6.1.5 [expr.ref]) using (*this) (_N4868_.11.4.3.2 [class.this]) as the postfix-expression to the left of the . operator...

12. Change 11.4.5 [class.ctor] paragraph 7 as indicated:

...The implicitly-defined default constructor performs the set of initializations of the class that would be performed by a user-written default constructor for that class with an empty mem-initializer-list no ctor-initializer (11.9.3 [class.base.init]) and an empty function body compound-statement...

13. Change 11.9.3 [class.base.init] paragraph 4 as indicated:

...After the call to a constructor for class X has completed, if a member of X is neither specified in the constructor's mem-initializers, nor default-initialized, nor value-initialized, nor given a value during execution of the compound-statement of the body of the constructor, the member has indeterminate value.

14. Change the last bullet of 11.9.3 [class.base.init] paragraph 5 as indicated:

• Finally, the body compound-statement of the constructor body is executed.

15. Change Clause 14 [except] paragraph 4 as indicated:

A function-try-block associates a handler-seq with the ctor-initializer, if present, and the function-body compound-statement. An exception thrown during the execution of the initializer expressions in the ctor-initializer or during the execution of the function-body compound-statement transfers control to a handler in a function-try-block in the same way as an exception thrown during the execution of a try-block transfers control to other handlers. [Example:

    int f(int);
    class C {
        int i;
        double d;
    public:
        C(int, double);
    };

    C::C(int ii, double id)
    try
        : i(f(ii)), d(id)
    {
        // constructor function body statements
    }
    catch (...)
    {
        // handles exceptions thrown from the ctor-initializer
        // and from the constructor function body statements
    }

—end example]

16. Change 14.3 [except.ctor] paragraph 2 as indicated:

When an exception is thrown, control is transferred to the nearest handler with a matching type (14.4 [except.handle]); “nearest” means the handler for which the compound-statement, compound-statement or ctor-initializer, or function-body following the try keyword was most recently entered by the thread of control and not yet exited.