extern(C++, ns)

Daniel Murphy via Digitalmars-d digitalmars-d at puremagic.com
Sun Jan 17 03:55:23 PST 2016


On 17/01/2016 6:09 AM, Walter Bright wrote:
> On 1/16/2016 6:26 AM, Daniel Murphy wrote:
>> Nobody
>> wants conflicting symbols in a module, and nobody wants to cram all of
>> their C++
>> namespace bindings inside a single D source file to avoid getting
>> namespace
>> symbol conflicts.
>
> D's namespace system does not suffer from those faults.

Sure it does.  Here's the situation:

I have two C++ headers in a library:

library\a.h:

namespace "mylib"
{
void funca() { ... }
}

library\b.h:

namespace "mylib"
{
void funcb() { ... }
}

I want to create D bindings and keep a similar import layout.  So I make:

module library.a;

extern(C++, mylib) void funca();

and

module library.b;

extern(C++, mylib) void funcb();

And now I have two library namespace symbols I never wanted.  I just 
wanted to mangle the same as the C++ symbols. D's module system already 
takes care of resolving conflicts.

So now we have two public symbols called 'mylib', and because they 
conflict they can't be used to disambiguate eg 'someotherlib.funca' with 
'library.a.funca'.

The only advantage of the current system I've seen presented is that you 
can now have multiple conflicting symbols in the same module.  I can see 
how that's useful in C++, but I don't think it helps _binding_ to C++ at 
all.  Or how it's worth the mess the extra symbols cause.


More information about the Digitalmars-d mailing list