Re: Const declaration in header files
On May 26, 1:13 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On May 26, 6:28 am, "Alf P. Steinbach" <al...@start.no> wrote:
* Paavo Helde:
On May 24, 10:46 pm, Paavo Helde <nob...@ebi.ee> wrote:
"Stephen Howe" <sjhoweATdialDOTpipexDOTcom> kirjutas:
2) What about the last two statements with const missing and place=
d
in a header file
char SomeConst5[] = "A value 3";
char *SomeConst6 = "A value 4";
The const you dropped is not the top-level one, so it does not
have any significance here.
In the second line. In the first, it changes the linkage.
Yes, you are right. I was not prepared to have yet more
subtleties, especially such seemingly illogical ones. It's
my fault I know, but I cannot understand why should const
char array have different linkage than variable char array?
Probably something to do with C legacy?
The two declarations shown above do not have top-level const.
They provide assignable variables. Since they're assignable
variables, not 'const', they have external linkage by default.
The real question here is:
char const SomeConst[] = "A value" ;
Does SomeConst have external linkage, or internal?
Internal.
It's const.
Well, that's what I think it should be, too. But I can't find
anything in the standard to back it up.
Intuitively,
I would say internal (and g++, Sun CC and VC++ agree with me),
but I can't find anything in the standard to back this up.
=A73.5/3 would apply if the object, the array, itself was
declared const.
But here it's seemingly the elements that are const, and
seemingly that the array effective constness stems from arrays
not being assignable on their own.
Exactly. In C, the standard says explicitly that there's no
such thing as a const array. The C++ standard doesn't say that
in so many words, but it does say that "Any type of the form
``cv-qualifier-seq array of N T'' is adjusted to ``array of N
cv-qualifier-seq T,[ ...]'', which means that even if you write:
typedef int A[10];
A const a ;
The type of a is array of 10 const int, and the const-ness is
not top level.
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?
And
if this has internal linkage, how is it different from:
struct Toto
{
int const i ;
} ;
Toto x = { 43 } ;
In both cases, we have an agglomerate in which all elements are
const (but the agglomerate itself is not declared const).
cv-qualification of elements of a struct does not transfer to
the struct itself.
I know, but according to the standard, the same is true of
arrays. Only more so, because you can't declare an object of
array type const.
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.
With regards to the struct above: I rather like the idea that a
PODS in which all elements are const would cause objects of that
type to be const as well, but that would definitely be an
extention, or a change in the language (and it's probably not
important enough to bother with).
Only distantly relevant to the current discussion: I don't see
anything forbidding a union to contain a const object either,
e.g.:
union U { int const a; double b ; } ;
I don't quite see how it could work, however. (Unions are being
reworked in the current draft, to remove a lot of the
restrictions. I'm not sure how this affects const elements in
unions, however.)
--
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