[WIN32: HELP ME !] pointers to extern data not constant on Win32 ???
From: Cyrille Chepelov <chepelov calixo net>
To: dia-list gnome org
Subject: [WIN32: HELP ME !] pointers to extern data not constant on Win32 ???
Date: Mon, 6 Aug 2001 19:59:57 +0200
Hi all, but Hans in particular.
I had put a huge mess in properties.c (the CVS has been a witness of
only a small part of it...), and got fed up with that.
So I started doing surgery on that module, shell-and-mortar style. The
result is going to be very clean I think, and I'm extremely pleased with how
it shapes (there's going to be almost no object-visible consequences, except
a trivial signature change in object->ops->get/set_props()).
PROBLEM: I just stumbled upon that comment block:
/* HB: exporting the following two vars by GIMPVAR==dllexport/dllimport,
* does mean the pointers used below have to be calculated
* at run-time by the loader, because they will exist
* only once in the process space and dynamic link libraries may be
* relocated. As a result their address is no longer constant.
* Indeed it causes compile time errors with MSVC (initialzer
* not a constant).
* To fix it they are moved form properties.c and declared as static
* on Win32
*/
Using ELF binaries, there is a relocation too ; this doesn't make the
initializers that non-constant (they are constant for the life of the
process, after all). Is the above still true using the latest MSVC ?
If it's the case, I'm screwed: what I'm set to do is to define
typedef PropertyTypeOps *PropertyType;
(load/save_prop, get/reset/set_from_widget, new/free/copy all becomes
methods of the Property "object"). And then, I wanted to do a trivial:
extern PropertyType PROP_TYPE_INVALID;
extern PropertyType PROP_TYPE_CHAR;
extern PropertyType PROP_TYPE_BOOL;
extern PropertyType PROP_TYPE_INT;
extern PropertyType PROP_TYPE_INTARRAY;
extern PropertyType PROP_TYPE_ENUM;
... etc ... to avoid the whole registration nonsense, and let the compiler,
linker and loader do that work for us.
In the module which defines a given property type, the methods are defined
static, and we would have this :
static PropertyTypeOps {
// ...
};
PropertyType PROP_TYPE_INT = &PropertyTypeOps;
If I understood properly the limitations of the Win32 platform, we can't do
that and have PROP_TYPE_INT appear in a constant initialiser. Can we ?
I would *really* like to avoid those solutions:
a) do some register_property_type() plumbing (and then comes the
"identifier registry" and "Oh, I forgot to call the init() routine
nonsense)
b) make all methods extern, and make a copy of all PropertyTypeOps
structures private to each DLL.
I've attached an example which I believe should work on Win32 ; if it works
(or if it can be made to work in an elegant way), I believe I can proced
with my restructuring the way I want to do. This code compiles and links
with gcc -ansi -pedantic. What does it give on MSVC ? What happens if bar.c
is now in a DLL loaded by LoadLibrary() ?
Thanks in advance !
-- Cyrille
--
Grumpf.