Menu
Search

Forums

Forum Index

Thread overview
D has better way to bind to C++ than to D.
Feb 22, 2023
Hipreme
Feb 22, 2023
Walter Bright
Feb 22, 2023
Paul Backus
Feb 23, 2023
Mathias LANG
Feb 23, 2023
Dukc
February 22, 2023
Gravatar of HipremePosted by HipremeReply
Hipreme
Gravatar of Hipreme


Reply

Given the following situation: I want to use an externally defined D symbol in my current library without adding it as a dependency.

  • I don't want to use an import path to bind to a symbol in D because this would complicate even more my build system, we already do it from C by doing: extern(C) void something();

We already can bind to a C++ symbol within a namespace by doing:
extern(C++, "some_namespace").

The same can't be said for D. We can't pass a module name which the function is being resided.

The practical example right now is that I have my own type conversion functions, located in hip.util.conv.

I wanted to use the symbol as:

extern(D, "hip.util.conv") extern TO to(TO)(FROM);

Even in an untemplated format, that would help me: (like passing an optional symbol saying it is a template.

extern(D, "hip.util.conv", to) extern string to(int);

I know this is not gonna happen right now but this has a lot of use cases and it currently underused because one would need to actually use a D mangler library.

February 22, 2023
Gravatar of Walter BrightPosted by Walter Bright
in reply to Hipreme		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Hipreme


Reply
I do it by simply declaring the function with C linkage: extern(C)
February 22, 2023
Gravatar of Paul BackusPosted by Paul Backus
in reply to Hipreme		Reply
Paul Backus
Gravatar of Paul Backus
Posted in reply to Hipreme


Reply

On Wednesday, 22 February 2023 at 19:26:40 UTC, Hipreme wrote:

>

Given the following situation: I want to use an externally defined D symbol in my current library without adding it as a dependency.

  • I don't want to use an import path to bind to a symbol in D because this would complicate even more my build system, we already do it from C by doing: extern(C) void something();

I think the real question here is, why don't you want to do this using import? What's the actual root cause of this "complication" you refer to? Better to address that problem directly than to add a new language feature as a workaround.

February 23, 2023
Gravatar of Richard (Rikki) Andrew CattermolePosted by Richard (Rikki) Andrew Cattermole
in reply to Walter Bright		Reply
Richard (Rikki) Andrew Cattermole
Gravatar of Richard (Rikki) Andrew Cattermole
Posted in reply to Walter Bright


Reply
That works except now the name can conflict with other C libraries ext.
So you either make the name less desirable to use or add mangling extra.
Not great solutions.

I'm gonna add this to my list of things I need to consider for the export DIP, since its redesigning how symbols work, the main question I have right now is how generic this needs to be.

Not that I exactly agree that you should run into this particular issue.
February 23, 2023
Gravatar of Mathias LANGPosted by Mathias LANG
in reply to Paul Backus		Reply
Mathias LANG
Gravatar of Mathias LANG
Posted in reply to Paul Backus


Reply

On Wednesday, 22 February 2023 at 20:22:18 UTC, Paul Backus wrote:

>

On Wednesday, 22 February 2023 at 19:26:40 UTC, Hipreme wrote:

>

Given the following situation: I want to use an externally defined D symbol in my current library without adding it as a dependency.

  • I don't want to use an import path to bind to a symbol in D because this would complicate even more my build system, we already do it from C by doing: extern(C) void something();

I think the real question here is, why don't you want to do this using import? What's the actual root cause of this "complication" you refer to? Better to address that problem directly than to add a new language feature as a workaround.

I agree, you shouldn't do that. But having extern symbols in a module is currently useless. I had a fix for it but Walter rejected it: https://github.com/dlang/dmd/pull/12839

February 23, 2023
Gravatar of DukcPosted by Dukc
in reply to Hipreme		Reply
Dukc
Gravatar of Dukc
Posted in reply to Hipreme


Reply

On Wednesday, 22 February 2023 at 19:26:40 UTC, Hipreme wrote:

>

Even in an untemplated format, that would help me: (like passing an optional symbol saying it is a template.

extern(D, "hip.util.conv", to) extern string to(int);

Yeah, we're supposed to define or generate a header module that has the same name as the real module. It can probably be also accomplished with some really ugly pragma(mangle, "...") trickery, but I agree that defining module names in extern(D) would be much nicer and sometimes a better solution than a header file for every linked-to source file. D ABI should be just as practical for separate compilation as C and C++ ABIs.