bottom line up front: I want pragma(mangle, "name")

I'd like to be able generate references to other functions in templates and stuff


mixin template Template() {
        extern(C) void test(); /* I want this to call test() */
}

struct Test {
        mixin Template!();
        void mything() { test(); }
}



Why is it useful? Previously I've wanted to play with generating C calls with opDispatch, and today I was thinking we could generate C++ interfacing this way.

dmd can call a great deal of C++ already, but it doesn't include constructors. We can work around it:

extern(C) void _ZN5ClassC1Ev(Class* c); // the C++ constructor
Class c;
_ZN5ClassC1Ev(&c);

and what would be nice is to be able to mixin some function that could generate that mangle automatically and call it for us.



A solution to this specific thing is to add C++ constructor mangling to the extern(C++) support.

But I think the general solution is pragma(mangle), that's been discussed before.

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:outrzhenaycnbogzwsfb@forum.dlang.org...
>
> A solution to this specific thing is to add C++ constructor mangling to the extern(C++) support.
>

And this is the only complete way, unless you can guarantee the C++ calling conventions can be simulated with extern(C)

> But I think the general solution is pragma(mangle), that's been discussed before.

https://github.com/D-Programming-Language/dmd/pull/1085

On Friday, 11 January 2013 at 14:27:35 UTC, Adam D. Ruppe wrote:
>
> A solution to this specific thing is to add C++ constructor mangling to the extern(C++) support.
>
> But I think the general solution is pragma(mangle), that's been discussed before.

there is some problem with C++ constructor(and other special functions), on windows it has stdcall format with @0 or @1 at the end in place of size, so u can't just get required size for its data, also there is NO standard ABI for c++, there is no standard calling convention, no way(except by mangling) to detect which runtime u will need, imagine how to use c++ RAII classes and templates, even if the std::string dropped there is not much use for such code.
you'll end up implementing compiler rather then D feature, i think Walter already do what's was possible without reinventing the compiler.

i had an a idea once to use asm statements to load and call c++ ctors or other special functions, it works but totally not portable even if would be implemented with effecient CTFE code generation...

closest thing one may to do is to use clang lib to get name mangling and possibly attach it's codegen or JIT to embedd within D code...

sorry if this message is a bit agressive and unclear

On Friday, 11 January 2013 at 15:00:26 UTC, Daniel Murphy wrote:
> And this is the only complete way, unless you can guarantee the C++ calling conventions can be simulated with extern(C)

Guarantees aren't terribly important to me... I'm doing a lot of hacks as it is. Of course if the compiler can make it all just work, that'd be great. I'm convinced there's still more practical low hanging fruit for more C++ interop.

> https://github.com/D-Programming-Language/dmd/pull/1085

Excellent, let's get it merged. I can't imagine it breaking any existing code and giving us this flexibility will let us do more practical hacks.

On Friday, 11 January 2013 at 15:02:02 UTC, evilrat wrote:
> *snip* also there is NO standard ABI for c++

Indeed, but "works for me" is good enough for me, and pragma(mangle) is enough to make that happen at least.

One of the benefits of lower level languages is you have the option of telling the compiler "trust me, this is ok" and it goes along with you. pragma(mangle) is kinda like casting void* for the linker - asking the compiler to trust you to get things done despite all kinds of problems it can't prove itself.

On Friday, 11 January 2013 at 15:19:23 UTC, Adam D. Ruppe wrote:
> On Friday, 11 January 2013 at 15:00:26 UTC, Daniel Murphy wrote:
>> And this is the only complete way, unless you can guarantee the C++ calling conventions can be simulated with extern(C)
>
> Guarantees aren't terribly important to me... I'm doing a lot of hacks as it is. Of course if the compiler can make it all just work, that'd be great. I'm convinced there's still more practical low hanging fruit for more C++ interop.
>
>> https://github.com/D-Programming-Language/dmd/pull/1085
>
> Excellent, let's get it merged. I can't imagine it breaking any existing code and giving us this flexibility will let us do more practical hacks.

but for more c++ interop you would need to know:
1) data(struct/class) size to malloc enough space
2) appropriate constructor and arguments(can be parsed and matched with existing schemes, only 3 major compiler mangling schemes anyway...)
3) placement new(can try to use same schemes to get c++ runtime version from mangling matched in 2)
4) use asm statements to pass your new c++ 'this'(from p.1) if any to placement new (p.3)
5) call your ctor from p.2
6) only now you have your C++ object constructed within D

the 1) is the biggest problem, only this is already enough to block the way down