Re: Const declaration in header files
On May 27, 11:26 am, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On May 26, 1:13 pm, "Alf P. Steinbach" <al...@start.no> wrote:
There is however a non-normative note at the end of =A78.3.4/1
that attempts to explain this. Presumably what it's meant to
explain is that the /intent/ of that paragraph is that
cv-qualification of array elements transfer to the array
object itself.
A very feeble attempt, IMHO. But perhaps sufficient if it were
normative.
Anyway, it explicitly says "internal linkage".
Where?
<q>
Note: an "array of N cv-qualifier-seq T" has cv-qualified type;
</q>
which I (now I see, explained below, probably incorrectly,
although opinions differ) read as an attempted explanation
that the element CV-qualification is transferred to the array
object itself, and continues, emhpasis added
<q>
such an array has *internal linkage* unless explicitly declared 'extern=
'
(7.1.5.1) and must be initialized as specified in 8.5.
</q>
That'll teach me to only look at the latest draft for such
things. The second part you quote above has been dropped in the
latest draft. Which is curious, because of course, the only
real intention of this that I can see is to ensure internal
linkage.
Of course if it were taken literally it would raise the issue
of auto variables with internal linkage.
Maybe that's why it was dropped. Or more accurately, replaced
by "see 3.9.3". Which says in its paragraph 2: "Any
cv-qualifiers applied to an array type affect the array element
type, not the array type (8.3.4)." And we're back to where we
started.
In the C++0x draft, at least my old version, the latter quoted
part is removed, and instead there is a reference to =A73.9.3
about CV-qualification, where it's made clear that my
interpretation above is not the one to be adopted in C++0x,
Except that "an `array of N cv-qualifier-seq T' has cv-qualified
type" seems to directly contradict "Any cv-qualifiers applied to
an array type affect the array element type, not the array
type". (The contradiction is in the "not the array type".)
So someone has been doing something, but it still looks like a
case of the left hand not knowing what the right hand is doing
to me. And quite frankly, I'd prefer that arrays of const T
behave as const array of const T. (Actually, I'd prefer that
const didn't affect the linkage, and that arrays behaved like
other composite types, i.e. with copy, no implicit conversion to
pointer, etc., etc. But it's far too late for either of those
changes.)
Current and C++0x
=A73.9.3/2
"Any cv-qualifiers applied to an array type affect the array
element type, not the array type (8.3.4)."
The change in =A78.3.4/1 wording, removal of that part about
internal linkage, follows core language Defect Report #112
discussion,
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#112
which touches on the linkage issue but does not resolve it or
really discuss it (the only concern is that "volatile" should
not result in internal linkage).
Hm.
I see we're finding most of the same passages (although I'd
missed the DR).
[snip]
Anyhow, I think it's all vague enough for me to raise an issue
with the committee. I'm not sure, but judging from the behavior
of the compilers I've tested, I think that there is more or less
a consensus that the const-ness of the array elements *should*
cause internal linkage (as if the array itself were const); it's
just a question of making this clear in the wording of the
standard.
I agree, good idea.
I've done so, but I really miss csc++ for this. The committee
reflectors seem more adapted to something more concrete, after a
bit of preliminary discussion.
Anyway, while I'm not totally happy with the idea that arrays
behave differently from other composite types (all elements
const does not imply composite const), arrays behave differently
from other composite types in so many other ways, and in the
absence of anyway to declare an array const, I rather think that
the best (most intuitive) solution is for the cv-qualification
of the array to be exactly that of the cv-qualification of its
elements. (It isn't in C, but in practice, in C, it doesn't
matter, since the const-ness of the array would have no
practical effects.)
Anyway, we'll see what comes of it, but in the meantime, I
wouldn't count on it being any particular way in a given
compiler. If I think it might matter, I'll explicitly add a
static or an extern (depending on what I want).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34