www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D2.0 cpp interfacing: what is a C++ unsigned long counterpart in D?

reply "Denis Koroskin" <2korden gmail.com> writes:
I'm currently writing a program that interfaces with C++.
C++ code uses a lot of 'unsigned long', which equals to 'unsigned int', or  
just 'unsigned', but is mangled differently.

In particular, C++ mangles unsigned long as 'K', and I can't find a D  
counterpart that would be mangled similarly.
This results in an unaccessible function (it is unresolved at link time).

Any thoughts?
Oct 03 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Denis Koroskin wrote:
 I'm currently writing a program that interfaces with C++.
 C++ code uses a lot of 'unsigned long', which equals to 'unsigned int', 
 or just 'unsigned', but is mangled differently.
 
 In particular, C++ mangles unsigned long as 'K', and I can't find a D 
 counterpart that would be mangled similarly.
 This results in an unaccessible function (it is unresolved at link time).
 
 Any thoughts?

The problem is there is no way to express in D both an unsigned and an unsigned long, since they are both uints in D. I don't know of a way around this, other than changing the C++ code.
Oct 03 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 03 Oct 2009 22:47:53 +0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Denis Koroskin wrote:
 I'm currently writing a program that interfaces with C++.
 C++ code uses a lot of 'unsigned long', which equals to 'unsigned int',  
 or just 'unsigned', but is mangled differently.
  In particular, C++ mangles unsigned long as 'K', and I can't find a D  
 counterpart that would be mangled similarly.
 This results in an unaccessible function (it is unresolved at link  
 time).
  Any thoughts?

The problem is there is no way to express in D both an unsigned and an unsigned long, since they are both uints in D. I don't know of a way around this, other than changing the C++ code.

That's not always possible. Imagine LGPL'd code, or code which is distributed in precompiled form only (header + library).
Oct 03 2009
parent reply BCS <none anon.com> writes:
Hello Denis,

 That's not always possible. Imagine LGPL'd code, or code which is
 distributed in precompiled form only (header + library).
 

would, explicitly stating the mangled name work? pragam(mangle, "mangled name") // proposed feature extern(C++) uint SomeFunction();
Oct 03 2009
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-10-03 17:13:45 -0400, BCS <none anon.com> said:

 Hello Denis,
 
 That's not always possible. Imagine LGPL'd code, or code which is
 distributed in precompiled form only (header + library).
 

would, explicitly stating the mangled name work? pragam(mangle, "mangled name") // proposed feature extern(C++) uint SomeFunction();

Why not just: extern(C++, "mangled name") uint SomeFunction(); where "mangled name" could be any constant expression? Whatever the syntax, this is a great idea. With constant expressions for mangled names someone could create a compile-time function or a template creating mangled names for namespaced functions and member functions. You could change that function/template to match any C++ compiler you want. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Oct 03 2009
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 04 Oct 2009 01:48:38 +0400, Michel Fortin  
<michel.fortin michelf.com> wrote:

 On 2009-10-03 17:13:45 -0400, BCS <none anon.com> said:

 Hello Denis,

 That's not always possible. Imagine LGPL'd code, or code which is
 distributed in precompiled form only (header + library).

pragam(mangle, "mangled name") // proposed feature extern(C++) uint SomeFunction();

Why not just: extern(C++, "mangled name") uint SomeFunction(); where "mangled name" could be any constant expression? Whatever the syntax, this is a great idea. With constant expressions for mangled names someone could create a compile-time function or a template creating mangled names for namespaced functions and member functions. You could change that function/template to match any C++ compiler you want.

I thought about that, too. This is a good idea, but it's also too compiler-specific and somewhat error-prone. I also thought about some Mangler template, which is capable of generating a mangled name for a given function at compile time, and using it instead of some pre-generated string. This is a more generic solution, one could substitute different manglers for different compiler vendors. In this case, I could "typedef uint unsigned_long;" and my mangler would recognize unsigned_long and mangle it differently from uint. Just an idea...
Oct 03 2009
parent BCS <none anon.com> writes:
Hello Denis,

 On Sun, 04 Oct 2009 01:48:38 +0400, Michel Fortin
 <michel.fortin michelf.com> wrote:
 
 

extern(C++, "mangled name") uint SomeFunction(); where "mangled name" could be any constant expression? Whatever the syntax, this is a great idea. With constant expressions for mangled names someone could create a compile-time function or a template creating mangled names for namespaced functions and member functions. You could change that function/template to match any C++ compiler you want.

compiler-specific and somewhat error-prone.

It's a low level workaround and anyone who write them by hand is being foolish. The primary cases I see it being used in are be tool generated header files build from c++ header files and or object files or with some kind of template+CTFE support.
 I also thought about some Mangler template, which is capable of
 generating
 a mangled name for a given function at compile time, and using it
 instead
 of some pre-generated string.
 This is a more generic solution, one could substitute different
 manglers
 for different compiler vendors.
 In this case, I could "typedef uint unsigned_long;" and my mangler
 would  recognize unsigned_long and mangle it differently from uint.
 
 Just an idea...
 

Whatever the overall solution, I think something along the lines of Denis' or my idea is the correct primitive to build it on.
Oct 03 2009
prev sibling next sibling parent Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Sat, Oct 3, 2009 at 2:55 PM, Denis Koroskin <2korden gmail.com> wrote:
 I'm currently writing a program that interfaces with C++.
 C++ code uses a lot of 'unsigned long', which equals to 'unsigned int', or
 just 'unsigned', but is mangled differently.

 In particular, C++ mangles unsigned long as 'K', and I can't find a D
 counterpart that would be mangled similarly.
 This results in an unaccessible function (it is unresolved at link time).

 Any thoughts?

The type of C++ "unsigned long" depends on the target platform.
Oct 03 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 03 Oct 2009 21:50:06 +0400, Tomas Lindquist Olsen  
<tomas.l.olsen gmail.com> wrote:

 On Sat, Oct 3, 2009 at 2:55 PM, Denis Koroskin <2korden gmail.com> wrote:
 I'm currently writing a program that interfaces with C++.
 C++ code uses a lot of 'unsigned long', which equals to 'unsigned int',  
 or
 just 'unsigned', but is mangled differently.

 In particular, C++ mangles unsigned long as 'K', and I can't find a D
 counterpart that would be mangled similarly.
 This results in an unaccessible function (it is unresolved at link  
 time).

 Any thoughts?

The type of C++ "unsigned long" depends on the target platform.

Sure, but it's stands true for all types, not only "unsigned long". I'm on x86, and it is the same as unsigned int here. BTW, I worked around the issue with a wrapper function: // workaround.cpp int foo(unsigned long bar); // extern int foo(unsigned int bar) { return foo((unsigned long)bar); } but it's not too handy.
Oct 03 2009
prev sibling parent downs <default_357-line yahoo.de> writes:
Denis Koroskin wrote:
 I'm currently writing a program that interfaces with C++.
 C++ code uses a lot of 'unsigned long', which equals to 'unsigned int',
 or just 'unsigned', but is mangled differently.
 
 In particular, C++ mangles unsigned long as 'K', and I can't find a D
 counterpart that would be mangled similarly.
 This results in an unaccessible function (it is unresolved at link time).
 
 Any thoughts?

Why not define the respective types in object.d, like C_int, C_long, C_ulong, and have the compiler mangle them correctly? I mean, if we're proposing new features anyway ..
Oct 04 2009