Re: [Vala] Scoping error in public constant members

[Jürg Billeter <j bitron ch>]

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