C++ produces this symbol: ?asAssocArray@Variant@ep@@QEBA?AU?$SharedMap@U?$AVLTree@UVariant@ep@@U12@U?$Compare@UVariant@ep@@@2@@ep@@@2@XZ D produces this symbol: ?asAssocArray@Variant@ep@@QEBA?AU?$SharedMap@U?$AVLTree@UVariant@ep@@0U?$Compare@UVariant@ep@@@2@@ep@@@2@XZ The difference is that little 'U12@' vs '0'. The MS linker de-mangles both symbols to read identical, so I don't know what it means. The C declaration: namespace ep { struct Variant { ep::SharedMap<ep::AVLTree<ep::Variant, ep::Variant, ep::Compare<ep::Variant>>> asAssocArray() const; }; } // namespace The D declaration: extern (C++, ep) { struct Variant { SharedMap!(AVLTree!(Variant, Variant, Compare!Variant)) asAssocArray() const; } } All those things are extern(C++, ep), and they work properly on their own.
On a tangent, I'm having a lot of trouble with the fact that MSVC mangles classes differently than struct's... I feel like I need a way to control which to choose on the D side. UDA perhaps?
A(In reply to Manu from comment #1) > On a tangent, I'm having a lot of trouble with the fact that MSVC mangles > classes differently than struct's... I feel like I need a way to control > which to choose on the D side. UDA perhaps? An ugly workaround would be to specify the fully mangled name using pragma(mangle).
Here's another case: C++: ?CreateImplInternal@Component@ep@@IEAAPEAXU?$BaseString@D@2@U?$SharedMap@U?$AVLTree@UVariant@ep@@U12@U?$Compare@UVariant@ep@@@2@@ep@@@2@@Z D: ?CreateImplInternal@Component@ep@@IEAAPEAXU?$BaseString@D@2@U?$SharedMap@U?$AVLTree@UVariant@ep@@0U?$Compare@UVariant@ep@@@2@@ep@@@2@@Z The difference being that same little '0U' which is meant to be 'U12@U' again. C++ declaration: namespace ep { class Component : public RefCounted, public IComponent { void* CreateImplInternal(String ComponentType, Variant::VarMap initParams); }; } D declaration: extern (C++, ep) class Component : RefCounted, IComponent { void* CreateImplInternal(String componentType, Variant.VarMap initParams); } In both cases, the function involves, Variant::VarMap, which expands to: C++: ep::SharedMap<ep::AVLTree<ep::Variant, ep::Variant, ep::Compare<ep::Variant>>> D: SharedMap!(AVLTree!(Variant, Variant, Compare!Variant)) That's the same type as the return value in the first issue, with the same problem in the symbol name. This is a pretty long symbol name, but the missing 'U12@' seems deterministic.
Need complete examples, not undefined names.
*sigh*, like everything, this only appears when the case becomes sufficient complex, and reduction takes ages. I was hoping you'd able to look at the difference in the mangled names, and infer what the problem is by the difference in attributes. Assuming you understand the mangled names, it should be pretty revealing.
The mangler: https://github.com/D-Programming-Language/dmd/blob/master/src/cppmangle.d is useful for figuring out what the various things, like Q vs U, mean.
Do you still see this ? Without a proper way to reproduce, I don't know what we can do about this bug.