> I'm saying you don't need to have it as a DLL, just a bit of linked-in C.

Allegro is already distributed as a DLL (as well as a static library), so one would use the same code either from C or D. There is no need to bloat one's computer with my own version.

>
> The problem is that, in D, a declaration is a definition. So
>
>     int x;
>
> will declare and define x. The trick to referencing a C global variable is to make a module, let's say foo.d:
> -------------------
> extern (C) int x;
> -------------------
>
> And then in your code:
> -----------------------
> import foo;
>
> ... and then refer to foo.x ...
> -----------------------
>
> but do NOT link in foo.obj. You'll find this trick is used in std.c.stdio
to
> refer to _iob[]. stdio.obj is NOT added to phobos.lib, and so the linker will look elsewhere for a definition of _iob[].
>
>

Thanks a lot. I will follow a better approach, in my opinion: provide a 2nd dll with getters/setters, and be consistent as to not having global variables, which is a bad idea anyway.

Shouldn't you consider D not 'defining' external variables ? Programmers will get confused (as I have).

No, no! You're not getting me

C client code can "see" variables exported from DLLs. D cannot.

So, why not just have a *very* thin wrapper written in C, with suitable D declarations, for getting what you want at almost no cost?

"Achilleas Margaritis" <axilmar@in.gr> wrote in message news:c6hdn4$bfc$1@digitaldaemon.com...
> > I'm saying you don't need to have it as a DLL, just a bit of linked-in C.
>
> Allegro is already distributed as a DLL (as well as a static library), so one would use the same code either from C or D. There is no need to bloat one's computer with my own version.
>
>
>

"Achilleas Margaritis" <axilmar@in.gr> wrote in message news:c6hed4$cga$1@digitaldaemon.com...
> Shouldn't you consider D not 'defining' external variables ? Programmers will get confused (as I have).

I considered that for a while. But the situation seemed to come up so rarely, and there was a reasonable workaround, and since exporting variables is generally considered a bad idea anyway, that I decided to leave it as is.

Walter wrote:

> The problem is that, in D, a declaration is a definition. So
> 
>     int x;
> 
> will declare and define x. The trick to referencing a C global variable is
> to make a module, let's say foo.d:
> -------------------
> extern (C) int x;
> -------------------
> 
> And then in your code:
> -----------------------
> import foo;
> 
> ... and then refer to foo.x ...
> -----------------------
> 
> but do NOT link in foo.obj. You'll find this trick is used in std.c.stdio to
> refer to _iob[]. stdio.obj is NOT added to phobos.lib, and so the linker
> will look elsewhere for a definition of _iob[].
> 
> 

Good to know that this is possible!  I was wondering how this was done.  A couple of weeks ago, I ran into troubles trying to find a way to access the global errno variable (supposed to be accessible for determining the last error number) on Linux using D.  It was easy enough to access functions like perror(), but all attempts to access the variable failed.

It may be bad design at the system level, but apparently that's the way some things are done :-(.

"John Reimer" <brk_6502@NOSP_AM.yahoo.com> wrote in message news:c6i1jq$1ak7$1@digitaldaemon.com...
> Good to know that this is possible!  I was wondering how this was done.
>   A couple of weeks ago, I ran into troubles trying to find a way to
> access the global errno variable (supposed to be accessible for
> determining the last error number) on Linux using D.  It was easy enough
> to access functions like perror(), but all attempts to access the
> variable failed.

There's std.c.linux.linux.getErrno() to get the linux errno value.

In article <c6hg63$f96$1@digitaldaemon.com>, Matthew says...
>
>No, no! You're not getting me
>
>C client code can "see" variables exported from DLLs. D cannot.
>
>So, why not just have a *very* thin wrapper written in C, with suitable D declarations, for getting what you want at almost no cost?

But this is exactly what I have done. I just did not do it for the full Allegro API; I did it for global variables only: I wrapped all global variables in getters/setters. It works fine.

In article <c6hk8t$m3o$1@digitaldaemon.com>, Walter says...
>
>
>"Achilleas Margaritis" <axilmar@in.gr> wrote in message news:c6hed4$cga$1@digitaldaemon.com...
>> Shouldn't you consider D not 'defining' external variables ? Programmers will get confused (as I have).
>
>I considered that for a while. But the situation seemed to come up so rarely, and there was a reasonable workaround, and since exporting variables is generally considered a bad idea anyway, that I decided to leave it as is.
>
>

Then what is the meaning for 'extern (C) <variable>' ?

Walter wrote:

> 
> There's std.c.linux.linux.getErrno() to get the linux errno value.
> 
> 

Ok... that's good to know.  Thanks.

-John

"Achilleas Margaritis" <Achilleas_member@pathlink.com> wrote in message news:c6ilbf$2btp$1@digitaldaemon.com...
> Then what is the meaning for 'extern (C) <variable>' ?

extern (C) can be applied to any declaration, and means that it will have
"C" name mangling and "C" calling conventions (for functions).