Topic: Static Const Members...


Author: rfg@netcom.com (Ronald F. Guilmette)
Date: Sun, 20 Feb 1994 20:05:31 GMT
Raw View
In article <mkohtala.761166321@snakemail.hut.fi> Marko.Kohtala@hut.fi writes:
>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>>>   class A {
>>>   public:
>>>      static const int x;
>>>   };
>
>>At this point, A::x is NOT a constant-expression.
>
>>>   const int A::x = 30;
>
>>From this point on, A::x IS a constant-expression.
>>But only in this compilation unit, and only from the initialization
>>onwards.

OK.  Would anyone care to speculate on that validity of the following
(somewhat different) code?

 const struct A { int x; } object = { 3 };

 int array[object.x];

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -




Author: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
Date: Fri, 11 Feb 1994 12:21:10 GMT
Raw View
moudgill@cs.cornell.edu ( Mayan Moudgill) writes:

>Consider the following construct:
[...]
>Now, is A::x a const int, or a static int that happens to be unchangeable?

Both.  But I think when you say `const int' you are really
asking if it is a constant-expression (ARM 5.19) that could be
used as an array bounds.

>   class A {
>   public:
>      static const int x;
>   };

At this point, A::x is NOT a constant-expression.

>   const int A::x = 30;



Author: mkohtala@lk-hp-19.hut.fi (Marko Kohtala)
Date: 13 Feb 94 19:05:21 GMT
Raw View
fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:

>>   class A {
>>   public:
>>      static const int x;
>>   };

>At this point, A::x is NOT a constant-expression.

>>   const int A::x = 30;

>From this point on, A::x IS a constant-expression.
>But only in this compilation unit, and only from the initialization
>onwards.

Sure, but let's look at it a bit closer.

So what we might want for a constant _of any type_ is:

a) Uninstantiated with known value (static instances when necessary)
b) Extern without known value
c) Instantiated with known value

Outside class these are achieved

a) const type c = value;
b) extern const type c;
c) extern const type c = value;

Would seem clear if similar class members could be

a) struct A { static const type c = value; };
b) struct A { static const type c; };
c) struct A { static const type c; }; extern const type A::c = value;

But no. a) is illegal for some reason. c) is also illegal while "const
type A::c = value;" does what "extern const type c = value;" does in
global scope.  "const type A::c = value;" could do the same what
happens for variables in global scope.

I have asked for a reason to this before, and still would like to know
it. I hope it is not only because ARM section 9.4 was not updated when
the behaviour of the global const was changed. Poor grounds for a
language feature.

I also would like to know if this could be fixed?  It causes enough
trouble.

Extern with known value (no static instances) would also be good (we
had it in C, didn't we?). Is there a way to do it?
--
---
Marko.Kohtala@hut.fi, Marko.Kohtala@compart.fi, Marko.Kohtala@ntc.nokia.com
Student at (not representative of) the Helsinki University of Technology
(This is an information virus: if you know of it, you are infected.)