Re: [Vala] Scoping error in public constant members

["Cayle Graumann" <cayle graumann gmail com>]

Jurg,

     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.  

Something like this:

vala:

namespace Test {
class Constant_Holder  {

        const  BigObject = new BigObject() 

}     
}



This would have to turn into something like :

h:  

extern const void * CONSTANT_HOLDER_BIGOBJECT;

c:

void CONSTANT_HOLDER_init() {
          static int initialized = 0;
         if(initialized == 0) {

                 CONSTANT_HOLDER_BIGOBJECT = BIGOBJECT_construct();
                 initialized = 1;
        }
}

On 9/1/06, Jürg Billeter <j bitron ch> wrote:

Hi Cayle,

On Don, 2006-08-31 at 16:17 -0500, Cayle Graumann wrote:
>      You are thinking of something like this?
>
> h file:
>
> static const int CONSTANT_HOLDER_X = 20;

Just that static const in the header.

> The static const int will give you a copy in every file that calls the
> header, but the scope will be limited to that object file, and so will

I'd expect that the compiler will be able to optimize the static const
away - unless you use &CONSTANT_HOLDER_X in your sources.

>  compile.  The #define method would be the most memory efficient ( you
> wouldn't even need the declaration in the c file as a static int, as
> it could be a define as well), because the preprocessor would replace
> every instance of CONSTANT_HOLDER_X with the value 20.  Now this would
> definitely work with fundamental datatypes, but I don't know if it
> would work for structs and pointers;

#define and static const should be nearly the same in an optimizing
compiler except that consts are typed and work with structs.

>
> I was thinking more on the lines of this:
>
> c file:
> const int CONSTANT_HOLDER_X = 20;
>
> h file:
> extern const int CONSTANT_HOLDER_X;
>
> This would get you only one memory allocation in the object file where
> the class is defined, and the compiler would optimize all calls in
> other compilation modules to point to that memory location.  This

That's right but #define and static const normally don't need any
runtime memory at all and the compiler can do things like constant
folding.

>  should work for object pointers as well as structs, as then the
> declaration would be
>
> c file:
> const GObject * CONSTANT_HOLDER_OBJECT = ......
>
> h file:
> extern const GObject * CONSTANT_HOLDER_OBJECT;
>
> The pointer is constant, not the value the pointer points to, and the
> compiler should know what to do from there.

How would you initialize the pointer constant, i.e. where do you get the
object pointer from? You can't call functions in initializers in C, as
far as I know...

> The trickiness about all this comes because we are compiling to C and
> not to machine code and so are inherently limited to the C scope
> limitations.  It would be nice to know how the early C++ compilers
> ( which were really C preprocessors) also handled some of these
> issues.

It's a lot less trickier than writing our own optimized assembler code.
A GCC frontend might be nice one day but it comes with its own problems.

Jürg