Marco van de Voort wrote:
Marco van de Voort wrote:
I'm not sure why you do it like this -- perhaps it's just a relic from ancient times when GPC didn't know about importing interfaces. In this case, I'd suggest to get rid of it. Otherwise, any ideas for fixing this are welcome.
The only other solution I can think of:
- such modules shouldn't be allow to initialise, and have stuff that must be
initialised global in the implementation part. (the part that is separately compiled)
How? When the module is compiled, the compiler doesn't know how it will be used?
(Note that I don't judge whether it should be unsupported or not. I just come up with some possible ideas)
That's ok, I just can't see them working out yet ...
[thinking] I see that I have made some assumptions, which I'll try to explain:
It depends on how your link between the header and the module sourcefile is.
When compiling the module sourcefile, is the header then checked? Iow are the header and implementation linked together (so that the header of module a is parsed before with the compilation of the module is started).
In this example, yes, because the header is also (explicitly) included in the module. For shared constants and types, that's useful (IMHO not as good as simply using/importing the module, but still better than copying the declarations). For variables and routines, it's kind of superfluous (it just might cause the compiler to warn if the actual declaration differs).
If that isn't done (the header is no true interface but a mere EXTERNAL declaration), then it is impossible, because the vars are declared twice, in header and module.
They're only once really declared (in the module), and twice external, once in the module (superfluous) and once in the program.
Otherwise a module could get a special pragma to declare it old style, and then the compiler should not generate initialisation code for interface variables. (mangled) Names of variables to be initialised globally could be stored in .gpi, and initialisation/finalisation code generated when the main module is compiled.
The problem is that the compiler run for the main program doesn't read the GPI file for the module (because it doesn't know about the module, it just sees the external declarations). If it did read the GPI file, everything would be fine, since that's how it is normally informed about the initializers to be called.
- All initialisation for the variabeles in the INTERFACE, are done by the
mainprogram.
Again how? All the compiler sees (in Ian's example) are `external' declarations, and initializing all external variables would in general be wrong.
Everything imported via #include should be initialised by the mainprogram, and it could be communicated back via de unit (non-object code) file. (gpi with GPC IIRC)
I don't think so. #include (which is basically the same as {$include} you might know from BP) just preprocesses the given source file. Someone might want to put some other kind of declarations in an include (which should not be initialized if external). So, include files should behave just as if the code was inserted in place of the include directive (that's also BP compatible, so I don't suppose you'd suggest otherwise ;-). So we can't use the include as an indication.
A main program then has to check all involved GPI files. Not only the modules that the mainprogram includes, but also deeper nested stuff.
That's actually a different issue (we've decided to solve it instead by letting each module's initializer call the initializers of modules it uses, and make sure that each initializer is called only once, using a flag -- as far as we know, this works well). The issue here is that the dependency (though direct, not even nested) is "hidden" from the compiler.
Frank