Created on 2012-06-18.00:00:00 last changed 131 months ago
[Moved to DR at the April, 2013 meeting.]
Proposed resolution (October, 2012):
Change 6.3 [basic.def.odr] paragraph 6 as follows:
There can be more than one definition...
...
in each definition of D, corresponding names, looked up according to 6.5 [basic.lookup], shall refer to an entity defined within the definition of D, or shall refer to the same entity, after overload resolution (12.2 [over.match]) and after matching of partial template specialization (13.10.4 [temp.over]), except that a name can refer to a non-volatile const object with internal or no linkage if the object has the same literal type in all definitions of D, and the object is initialized with a constant expression (7.7 [expr.const]), and
the value (but not the address) ofthe object isusednot odr-used, and the object has the same value in all definitions of D; and...
Change 6.6 [basic.link] paragraph 3 as follows:
A name having namespace scope (6.4.6 [basic.scope.namespace]) has internal linkage if it is the name of
a variable, function or function template that is explicitly declared static; or,
a non-volatile variable that is explicitly declared const or constexpr and neither explicitly declared extern nor previously declared to have external linkage; or
a data member of an anonymous union.
One of the criteria in 6.3 [basic.def.odr] paragraph 6 for when a entity is allowed to have multiple definitions is:
in each definition of D, corresponding names, looked up according to 6.5 [basic.lookup], shall refer to an entity defined within the definition of D, or shall refer to the same entity, after overload resolution (12.2 [over.match]) and after matching of partial template specialization (13.10.4 [temp.over]), except that a name can refer to a const object with internal or no linkage if the object has the same literal type in all definitions of D, and the object is initialized with a constant expression (7.7 [expr.const]), and the value (but not the address) of the object is used, and the object has the same value in all definitions of D; and
This wording is possibly not sufficiently clear for an example like:
const volatile int n = 0; inline int get() { return n; }
Presumably this code could not appear in multiple translation units, because the requirement that n “has the same value in all definitions” cannot be satisfied (the value of a volatile variable can change “by means undetectable by the implementation,” per 9.2.9.2 [dcl.type.cv] paragraph 7, so the value of n might be different in each translation unit). However, it might be good to make it explicit that “a const object” is not intended to apply to a volatile-qualified object.
Other points that were raised during the discussion of this issue were that it would probably be better to rephrase “the value (but not the address) of the object is used” in terms of the odr-use of the object, as well as questioning why a const volatile variable implicitly has internal linkage.
History | |||
---|---|---|---|
Date | User | Action | Args |
2014-03-03 00:00:00 | admin | set | status: drwp -> cd3 |
2013-10-14 00:00:00 | admin | set | status: dr -> drwp |
2013-05-03 00:00:00 | admin | set | messages: + msg4368 |
2013-05-03 00:00:00 | admin | set | status: ready -> dr |
2012-11-03 00:00:00 | admin | set | messages: + msg4043 |
2012-11-03 00:00:00 | admin | set | status: open -> ready |
2012-06-18 00:00:00 | admin | create |