[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[WIN32: HELP ME !] pointers to extern data not constant on Win32 ???



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.

#include "common.h"
#include <stdio.h>

static mystruct ms = {5 };
p_mystruct valptr = &ms;

void foo(void) {
  printf("foo: value=%d\n",valptr->value);
}

int main(int argc, char **argv) {
  foo();
  bar();
}
#include "common.h"
#include <stdio.h>

void bar(void) {
#if 0
  mystruct doesnt_compile;
  valptr = &doesnt_compile;
#endif
  printf("bar: value=%d\n",valptr->value);
}
typedef struct {
  int value;
} mystruct;

typedef const mystruct *const p_mystruct;

extern p_mystruct valptr;

void foo(void);
void bar(void);


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] Mail converted by Mofo Magic and the Flying D

 
All trademarks and copyrights are the property of their respective owners.

Other Directory Sites: SeekWonder | Directory Owners Forum

GuideSMACK