Title
Definition and use of “block scope” and “local scope”
Status
cd2
Section
6.4.3 [basic.scope.block]
Submitter
Alisdair Meredith

Created on 2007-08-06.00:00:00 last changed 178 months ago

Messages

Date: 2010-03-15.00:00:00

[Voted into WP at March, 2010 meeting.]

Date: 2009-10-15.00:00:00

Proposed resolution (October, 2009):

  1. Change 6.4.2 [basic.scope.pdecl] paragraph 2 as follows:

  2. [Note: a nonlocal name from an outer scope remains visible up to the point of declaration of the local name that hides it. [Example:

      const int i = 2;
      { int i[i]; }
    

    declares a local block-scope array of two integers. —end example] —end note]

  3. Change the section heading of 6.4.3 [basic.scope.block] from “Local scope” to “Block scope.”

  4. Change 6.4.3 [basic.scope.block] paragraph 1 as follows:

  5. A name declared in a block (8.4 [stmt.block]) is local to that block; it has block scope. Its potential scope begins at its point of declaration (6.4.2 [basic.scope.pdecl]) and ends at the end of its declarative region block. A variable declared at block scope is a local variable.
  6. Change 6.4.3 [basic.scope.block] paragraph 3 as follows:

  7. The name in a catch exception-declaration declared in an exception-declaration is local to the handler handler and shall not be redeclared in the outermost block of the handler handler.
  8. Change _N4868_.6.4.10 [basic.scope.hiding] paragraph 3 as follows:

  9. In a member function definition, the declaration of a local name at block scope hides the declaration of a member of the class with the same name...
  10. Change 6.6 [basic.link] paragraph 8 as follows:

  11. ...Moreover, except as noted, a name declared in a local at block scope (6.4.3 [basic.scope.block]) has no linkage...
  12. Change 6.9.3.3 [basic.start.dynamic] paragraph 1 as follows:

  13. ...For an object of array or class type, all subobjects of that object are destroyed before any local block-scope object with static storage duration initialized during the construction of the subobjects is destroyed.
  14. Change 6.9.3.3 [basic.start.dynamic] paragraph 2 as follows:

  15. If a function contains a local block-scope object of static or thread storage duration that has been destroyed and the function is called during the destruction of an object with static or thread storage duration, the program has undefined behavior if the flow of control passes through the definition of the previously destroyed local block-scope object. Likewise, the behavior is undefined if the function-local block-scope object is used indirectly (i.e., through a pointer) after its destruction.
  16. Change 6.9.3.3 [basic.start.dynamic] paragraph 3 as follows:

  17. If the completion of the initialization of a non-local non-block-scope object with static storage duration is sequenced before a call to std::atexit (see <cstdlib>, 17.5 [support.start.term]), the call to the function passed to std::atexit is sequenced before the call to the destructor for the object. If a call to std::atexit is sequenced before the completion of the initialization of a non-local non-block-scope object with static storage duration, the call to the destructor...

    [Editorial note: the occurrences of “non-local” in this change are removed by the proposed resolution for issue 946.]

  18. Change 8.4 [stmt.block] paragraph 1 as follows:

  19. ...A compound statement defines a local block scope (6.4 [basic.scope])...
  20. Change 8.5 [stmt.select] paragraph 1 as follows:

  21. ...The substatement in a selection-statement (each substatement, in the else form of the if statement) implicitly defines a local block scope (6.4 [basic.scope])...
  22. Change 8.5 [stmt.select] paragraph 5 as follows:

  23. If a condition can be syntactically resolved as either an expression or the declaration of a local block-scope name, it is interpreted as a declaration.
  24. Change 8.6 [stmt.iter] paragraph 2 as follows:

  25. The substatement in an iteration-statement implicitly defines a local block scope (6.4 [basic.scope]) which is entered and exited each time through the loop.
  26. Change 8.8 [stmt.dcl] paragraph 3 as follows:

  27. ...A program that jumps84 from a point where a local variable with automatic storage duration...
  28. Change 8.8 [stmt.dcl] paragraph 4 as follows:

  29. The zero-initialization (9.4 [dcl.init]) of all local block-scope objects with static storage duration (6.7.5.2 [basic.stc.static]) or thread storage duration (6.7.5.3 [basic.stc.thread]) is performed before any other initialization takes place. Constant initialization (6.9.3.2 [basic.start.static]) of a local block-scope entity with static storage duration, if applicable, is performed before its block is first entered. An implementation is permitted to perform early initialization of other local block-scope objects...
  30. Change 8.8 [stmt.dcl] paragraph 5 as follows:

  31. The destructor for a local block-scope object with static or thread storage duration will be executed if and only if the variable was constructed. [Note: 6.9.3.3 [basic.start.dynamic] describes the order in which local block-scope objects with static and thread storage duration are destroyed. —end note]
  32. Change 9.5 [dcl.fct.def] paragraph 7 as follows:

  33. In the function-body, a function-local predefined variable denotes a local block-scope object of static storage duration that is implicitly defined (see 6.4.3 [basic.scope.block]).
  34. Change the example in 11.3 [class.name] paragraph 2 as follows:

  35.   ...
      void g() {
        struct s;      // hide global struct s
                       // with a local block-scope declaration
      ...
    
  36. Change the example in 11.3 [class.name] paragraph 3 as follows:

  37.   ...
      void g(int s) {
        struct s* p = new struct s;   // global s
        p->a = s;                     // local parameter s
      }
    
Date: 2008-09-15.00:00:00

Notes from the September, 2008 meeting:

Reevaluating the relative prevalence of the two terms (including the fact that new uses of “block scope” are being introduced, e.g., in both the lambda and thread-local wording) led to CWG reversing its previous preference for “local scope.” The resolution will need to add a definition of “block scope” and should change the title of 6.4.3 [basic.scope.block].

Date: 2007-10-15.00:00:00

Notes from the October, 2007 meeting:

The CWG expressed a preference for the term “local scope.”

Date: 2007-08-06.00:00:00

The Standard uses the terms “block scope” and “local scope” interchangeably, but the former is never formally defined. Would it be better to use only one term consistently? “Block scope” seems to be more frequently used.

History
Date User Action Args
2010-03-29 00:00:00adminsetmessages: + msg2658
2010-03-29 00:00:00adminsetstatus: ready -> cd2
2009-11-08 00:00:00adminsetstatus: drafting -> ready
2008-10-05 00:00:00adminsetmessages: + msg1773
2008-10-05 00:00:00adminsetstatus: review -> drafting
2008-05-18 00:00:00adminsetmessages: + msg1645
2008-05-18 00:00:00adminsetstatus: drafting -> review
2007-10-09 00:00:00adminsetmessages: + msg1543
2007-10-09 00:00:00adminsetstatus: open -> drafting
2007-08-06 00:00:00admincreate