The program:

    final class Win32 {
        private this() { }

        static extern(Windows) void* GetProcAddress(void* p);
    }

    int main() {
        printf("gpa: %p\n", Win32.GetProcAddress(null));
        return 0;
    }

Produces a link error:

    test.obj(test)
     Error 42: Symbol Undefined __D4test5Win3214GetProcAddressWPvZPv@4

(presumably because the name mangling is being done despite the non-D linkage)

 -- andy

Andy Friesen wrote:

> The program:
> 
>     final class Win32 {
>         private this() { }
> 
>         static extern(Windows) void* GetProcAddress(void* p);
>     }
> 
>     int main() {
>         printf("gpa: %p\n", Win32.GetProcAddress(null));
>         return 0;
>     }
> 
> Produces a link error:
> 
>     test.obj(test)
>      Error 42: Symbol Undefined __D4test5Win3214GetProcAddressWPvZPv@4
> 
> (presumably because the name mangling is being done despite the non-D linkage)

err....

It still breaks even if you get the argument count right. :)

 -- andy

"Andy Friesen" <andy@ikagames.com> wrote in message news:ce0qef$2fmn$1@digitaldaemon.com...
> The program:
>
>      final class Win32 {
>          private this() { }
>
>          static extern(Windows) void* GetProcAddress(void* p);
>      }
>
>      int main() {
>          printf("gpa: %p\n", Win32.GetProcAddress(null));
>          return 0;
>      }
>
> Produces a link error:
>
>      test.obj(test)
>       Error 42: Symbol Undefined __D4test5Win3214GetProcAddressWPvZPv@4
>
> (presumably because the name mangling is being done despite the non-D
> linkage)

The name mangling must be done when within a scope, or the names will conflict from one class to the next. Having Windows calling convention supported for member functions is necessary for supporting COM.

I suggest instead using an alias:

private import std.c.windows.windows;
class Win32 {
    alias std.c.windows.windows.GetProcAddress GetProcAddress;
}

> The name mangling must be done when within a scope, or the names will
> conflict from one class to the next. Having Windows calling convention
> supported for member functions is necessary for supporting COM.
> 
> I suggest instead using an alias:
> 
> private import std.c.windows.windows;
> class Win32 {
>     alias std.c.windows.windows.GetProcAddress GetProcAddress;
> }
> 
> 

So what you're saying is that I'd have to use a huge list of aliases to import 400+ extern (Windows) functions from the module into the class. (this is what DWT needs to do).

Too bad an internal class import is deprecated.  It sure would make the job a lot easier. :-(

"John Reimer" <brk_6502@NOSP_AM.yahoo.com> wrote in message news:ce57bk$21a8$1@digitaldaemon.com...
>
> > The name mangling must be done when within a scope, or the names will conflict from one class to the next. Having Windows calling convention supported for member functions is necessary for supporting COM.
> >
> > I suggest instead using an alias:
> >
> > private import std.c.windows.windows;
> > class Win32 {
> >     alias std.c.windows.windows.GetProcAddress GetProcAddress;
> > }
> >
> >
>
> So what you're saying is that I'd have to use a huge list of aliases to
> import 400+ extern (Windows) functions from the module into the class.
> (this is what DWT needs to do).

Why does DWT need to do this?

> Too bad an internal class import is deprecated.

It isn't deprecated, I just don't see why it is used (beyond the forward reference issues, which have been slayed one by one).

> It sure would make the
> job a lot easier. :-(

Walter wrote:

>>So what you're saying is that I'd have to use a huge list of aliases to
>>import 400+ extern (Windows) functions from the module into the class.
>>(this is what DWT needs to do).
> 
> Why does DWT need to do this?

It's basically another case of SWT going through contortions brought around by its inability to be flexible.  DWT is, at present, following those contortions.

sed is your friend. ;)

 -- andy

Andy Friesen wrote:

> Walter wrote:
> 
>>> So what you're saying is that I'd have to use a huge list of aliases to
>>> import 400+ extern (Windows) functions from the module into the class.
>>> (this is what DWT needs to do).
>>
>>
>> Why does DWT need to do this?
> 
> 
> It's basically another case of SWT going through contortions brought around by its inability to be flexible.  DWT is, at present, following those contortions.

errrr, brain-typo.  That should read:

"It's basically another case of SWT going through contortions brought around by /Java's/ inability to be flexible."

 -- andy