trouble understanding definition of a declarative region

[Peter]

Section 3.3.1 of new C++ standard provides the following definition of
a declarative region:

"Every name is introduced in some portion of program text called a
declarative region, which is the largest part
of the program in which that name is valid, that is, in which that
name may be used as an unqualified name
to refer to the same entity.". The definition is followed by this
example:

int j = 24;
int main() {
int i = j, j;
j = 42;
}

According to an explanation following the example, the declarative
region of the first j includes the entire example. How does this not
contradict the definition of a declarative region? Obviously, the same
name ("j") can't be used to refer to the same entity in the entire
example, because first j (global) and second j (defined in main after
comma) refer to two distinct variables.

 

[Victor Bazarov]

Section 3.3.1 of new C++ standard provides the following definition of
a declarative region:

"Every name is introduced in some portion of program text called a
declarative region, which is the largest part
of the program in which that name is valid, that is, in which that
name may be used as an unqualified name
to refer to the same entity.". The definition is followed by this
example:

int j = 24;
int main() {
int i = j, j;
j = 42;
}

According to an explanation following the example, the declarative
region of the first j includes the entire example. How does this not
contradict the definition of a declarative region? Obviously, the same
name ("j") can't be used to refer to the same entity in the entire
example, because first j (global) and second j (defined in main after
comma) refer to two distinct variables.

What in the definition makes you think that the part of the program that
follows the declaration of the 'j' inside 'main' is included in the
declarative region of the global 'j'?

V

 

[Paul N]

What in the definition makes you think that the part of the program that
follows the declaration of the 'j' inside 'main' is included in the
declarative region of the global 'j'?

I'm guessing here, partly as I don't know what Peter may be thinking
and partly because I couldn't find N3337 and so am using N3242, but...

Peter seems to think that the part of main following the second j is
*not* part of the declarative region of the global j according to the
definition, because it can't be referred to there and so is on the
face of it contrary to the definition. However, the standard says,
after giving this example, "The declarative region of the first j
includes the entire example."

 

[Victor Bazarov]

I'm guessing here, partly as I don't know what Peter may be thinking
and partly because I couldn't find N3337 and so am using N3242, but...

Peter seems to think that the part of main following the second j is
*not* part of the declarative region of the global j according to the
definition, because it can't be referred to there and so is on the
face of it contrary to the definition. However, the standard says,
after giving this example, "The declarative region of the first j
includes the entire example."

Aha... The declarative region is a contiguous area in which the name
*may* be used, and perhaps Peter confuses that with the *scope* that is
not necessarily contiguous. The wording of the Standard is somewhat
convoluted, not easy to comprehend (at least for me). If I were to
explain the difference between the "declarative region" and "scope", I'd
probably be hesitant to find the right words to convey the meaning.
Scopes have everything to do with name resolution, declarative regions
OTOH are larger and can contain code in which the names aren't
necessarily *visible* (because they can be hidden) although they are
necessarily *valid*. The whole point, I believe, is not to confuse the
declarative regions and scopes.

V

 

[Peter]

What in the definition makes you think that the part of the program that
follows the declaration of the 'j' inside 'main' is included in the
declarative region of the global 'j'?

According to definition given before the example I'd guess declarative
region
of the global 'j' spans from the start of the example and ends right
before
local 'j' is declared in 'main'. Later the following comment is made
that
contradicts this:

"The declarative region of the first j includes the entire example."

 

[Peter]

Aha...  The declarative region is a contiguous area in which the name
*may* be used, and perhaps Peter confuses that with the *scope* that is
not necessarily contiguous.  The wording of the Standard is somewhat
convoluted, not easy to comprehend (at least for me).  If I were to
explain the difference between the "declarative region" and "scope", I'd
probably be hesitant to find the right words to convey the meaning.
Scopes have everything to do with name resolution, declarative regions
OTOH are larger and can contain code in which the names aren't
necessarily *visible* (because they can be hidden) although they are
necessarily *valid*.  The whole point, I believe, is not to confuse the
declarative regions and scopes.

I think the main problem with my reasoning is I though "visible" and
"valid"
were synonymous in this context which is wrong. But then again, what
does
"valid" really mean here? The definition of "valid" ("may be used as
an
unqualified name to refer to the same entity") doesn't enlighten me
enough. Basically, I don't understand how a hidden variable can be
valid.

In example I gave earlier, the global 'j' is obviously hidden from the
point of declaration of local 'j' in 'main' to the end of 'main', so
how is it 'valid' there? How can 'j' be used in that section of code
to refer to global j? I can use "::j", but does it still count as
"unqualified"?

 

[Peter]

Any more replies, please? Could you explain to me the concept
of a "valid" name according to the standard? I can't understand
how the global 'j' is "valid" between declaration point of local 'j'
and end of 'main'. In order for global 'j' to be "valid" there,
it should be possible to use the unqualified name 'j' from there
to refer to a global 'j', but that's impossible since global 'j'
is hidden (and therefore inaccessible) there. It can be accessed
by '::j', but that's a qualified name. What am I missing this time?

 

[Rui Maciel]

Section 3.3.1 of new C++ standard provides the following definition of
a declarative region:

"Every name is introduced in some portion of program text called a
declarative region, which is the largest part
of the program in which that name is valid, that is, in which that
name may be used as an unqualified name
to refer to the same entity.". The definition is followed by this
example:

int j = 24;
int main() {
int i = j, j;
j = 42;
}

According to an explanation following the example, the declarative
region of the first j includes the entire example. How does this not
contradict the definition of a declarative region? Obviously, the same
name ("j") can't be used to refer to the same entity in the entire
example, because first j (global) and second j (defined in main after
comma) refer to two distinct variables.

The definition of declarative region, as provided in the standard, is «the
largest part of the program (...) in which that name may be used as an
unqualified name to refer to the same entity».

Notice that the definition of «declarative region» is based on the word
"may". In standardeze, there is a difference between "may" and "shall",
which is important in this case. The word "may" represents a possibility
which might not materialise, contrary to the word "shall", which represents
an obligation.

In this case, the standard states that it is possible that, within a
declarative region, a name can be used to refer to the same entity, but it
is also possible that the name won't be used to refer to the same entity.
It's possible, but it doesn't always happen. Hence, the "may".

Then, there is a reason why the «declarative region» concept is complemented
with two additional concepts: potential scope and scope of a declaration.

According to the standard, the «scope» of a declaration is the possibly
discontinuous portion of the program where each particular name is valid,
and the scope differs from the potential scope by accounting for the
possibility that the name may be hidden.

Now, regarding the example, the declarative region of the first j is in fact
the whole program. That's because that, by declaring the first j, the
possibility of accessing that object is extended to the entire example. It
would still be possible to access the first j within the main function if
the second j wasn't declared. Yet, just because the name of the first j was
hidden it doesn't mean that it ceased to be potentially accessible within
that region. The possibility is still there, and if the second j was
renamed then the scope of the first j would again correspond to the
declarative region.

In short, «declarative region» refers to th region where a name is
potentially valid, even when it isn't actually valid. Hence, the example.


Rui Maciel

 

[Rui Maciel]

Aha... The declarative region is a contiguous area in which the name
*may* be used, and perhaps Peter confuses that with the *scope* that is
not necessarily contiguous. The wording of the Standard is somewhat
convoluted, not easy to comprehend (at least for me). If I were to
explain the difference between the "declarative region" and "scope", I'd
probably be hesitant to find the right words to convey the meaning.

The differente between declarative region and scope is made quite clear in
the standard. What is left a bit unclear is the difference between
declarative region and potential scope. That bit appears to have been left
out of the standard, and as it stands it appears that they are actually
synonyms.

Scopes have everything to do with name resolution, declarative regions
OTOH are larger and can contain code in which the names aren't
necessarily *visible* (because they can be hidden) although they are
necessarily *valid*. The whole point, I believe, is not to confuse the
declarative regions and scopes.

That is true if instead of «declarative region» you refer to «potential
scope». I suspect that the standard defines «potential scope» as a subset
of «declarative region», but it appears the standard isn't clear on what
bits of the «declarative region» are left out of «potential scope».

If «declarative region» and «potential scope» referred exactly to the same
thing then, yes, that assertion would be valid. The potential scope refers
to the portion of the code where a name is potentially valid, and the scope
defines the portion of the code where the name is in fact valid. So,
essentially we get the scope of a name if we take its potential scope and
exclude the potential scope of any other subsequent declaration which might
hide it.


Rui Maciel

 

[Peter]

Thank you for your detailed answer. Now I know
at least some of the pitfalls that can be
encountered while reading the standard.

 

[Jeeves]

What is left a bit unclear is the difference between

declarative region and potential scope. That bit appears to have been left
out of the standard, and as it stands it appears that they are actually
synonyms.

In the example declarative region and potential scope are differentiated WRT second ‘j’. Potential scope starts at the declaration of ‘j’ while declarative region starts at the enclosing ‘{’. Declarative region isused in several other places in the document as well. It appears that a declarative region is always delimited by a matching { } pair except in few cases such as split namespaces and templates. For sure, a clear definition of the declarative region would have been helpful to understand the standard..

Jeeves