Re: [Vala] Scoping error in public constant members

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

Jurg,

     You are thinking of something like this?

c file:

static int CONSTANT_HOLDER_X = 20;

h file:

const int CONSTANT_HOLDER_X = 20;
or
static const int CONSTANT_HOLDER_X = 20;
or
#define CONSTANT_HOLDER_X 20;

With the const int in the header, you will get linker errors, because the linker will complain of having too many of the same named variables in global scope unless the compiler is smart enough to do direct substitution, since you will have a copy created in global scope each and every time the header is used.  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 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;

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 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.

The current static method works for private constants because you have chosen to disallow class definitions crossing over into Vala files;

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 has been a long time since I did straight C, so if anyone else can think of anything I've left out, let everyone know.

Cayle

On 8/31/06, Jürg Billeter <j bitron ch> wrote:

Hi Cayle,

On Mit, 2006-08-30 at 22:50 -0500, Cayle Graumann wrote:
>         I have found another unexpected error.  The following code
> works correctly if Error3a and Error3b are in the same file, but if
> you separate them into different files, the vala compiler will compile
> them properly, however the C compilation step will complain about
> ERROR3_CONSTANT_HOLDER1_X not being defined in the second file.
> Looking at the C code generated by vala, you have defined public const
> variables as being static variables in the resulting C file, thus it's
> scope is not visible outside the c file.   Perhaps instead of being
> static, they should be global variables and declared as extern in the
> resulting c header file.  The current method would still be
> appropriate for private const variables.

Or maybe keep them static but just put public constants in the c header
file. That should use less memory or am I mistaken here?

Jürg