www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Name mangling and extern (x)

reply Andy Friesen <andy ikagames.com> writes:
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
Jul 25 2004
next sibling parent Andy Friesen <andy ikagames.com> writes:
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
Jul 25 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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;
}
Jul 26 2004
parent reply John Reimer <brk_6502 NOSP_AM.yahoo.com> writes:
 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. :-(
Jul 27 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"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. :-(
Jul 29 2004
parent reply Andy Friesen <andy ikagames.com> writes:
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
Jul 29 2004
parent Andy Friesen <andy ikagames.com> writes:
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
Jul 29 2004