• Denis Koroskin (7/7) Oct 03 2009 I'm currently writing a program that interfaces with C++.
• Walter Bright (4/13) Oct 03 2009 The problem is there is no way to express in D both an unsigned and an
• Denis Koroskin (4/16) Oct 03 2009 That's not always possible. Imagine LGPL'd code, or code which is
• BCS (5/8) Oct 03 2009 would, explicitly stating the mangled name work?
• Michel Fortin (13/23) Oct 03 2009 Why not just:
• Denis Koroskin (12/29) Oct 03 2009 I thought about that, too. This is a good idea, but it's also too
• BCS (7/39) Oct 03 2009 It's a low level workaround and anyone who write them by hand is being f...
• Tomas Lindquist Olsen (2/9) Oct 03 2009 The type of C++ "unsigned long" depends on the target platform.
• Denis Koroskin (9/23) Oct 03 2009 Sure, but it's stands true for all types, not only "unsigned long".
• downs (3/12) Oct 04 2009 Why not define the respective types in object.d, like C_int, C_long, C_u...

"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?

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.

"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).

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();

 

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/

"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).

  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.

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...

BCS <none anon.com> writes:

Hello Denis,

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

 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.
 

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.

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.

"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.

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 ..