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