Re: [Vala] Scoping error in public constant members

[Jürg Billeter <j bitron ch>]

Hi Cayle,

On Fre, 2006-09-01 at 09:27 -0500, Cayle Graumann wrote:
>      I agree that having the static const and #define are equivalent
> with optimizing compilers for fundamental datatypes, and I'd much
> rather have static const than the #define.  An optimizing compiler
> should be almost efficient at optimizing calls to extern const data as
> well though.   I had forgotten about not being able to call functions
> in initilizers in C -- for some reason I was thinking that had been
> relaxed in the C99 standard, but after looking at the spec (google is
> my friend) I see that has not changed.  If we had const pointers to
> objects, I guess we would have to call an initializer or constructor
> function before they could be used.

It must always be possible to compute values of constants at
compile-time and they can't be changed at run-time, that's not different
e.g. in C#. `const' is not the same as `final' in Java. constants get
computed at compile-time whereas `final' members get initialized at
run-time but the value may not be changed later on.

> Something like this:
>
> vala:
>
> namespace Test {
> class Constant_Holder  {
>
>         const  BigObject = new BigObject() 
>
> }    
> }

So this won't/can't be allowed.

> This would have to turn into something like : 
>
> h:  
>
> extern const void * CONSTANT_HOLDER_BIGOBJECT;

This should be
extern void * const CONSTANT_HOLDER_BIGOBJECT;

As you want a constant pointer, not a pointer to a constant object.

> c:
>
> void CONSTANT_HOLDER_init() {
>           static int initialized = 0;
>          if(initialized == 0) {
>
>                  CONSTANT_HOLDER_BIGOBJECT = BIGOBJECT_construct(); 
>                  initialized = 1;
>         }
> }

You can't set constants at run-time in C (and C#), so this approach
wouldn't work.

I hope it's a bit clearer now.

Jürg