On Tue, 19 Jan 2016 14:15:26 +0000, rsw0x wrote:
> On Tuesday, 19 January 2016 at 13:56:54 UTC, Manu wrote:
>> ...
>
> Sorry for the noise, but this is a very long thread. Can someone just
> summarize how C++ namespaces work when interfacing with D?
>
> I assumed they just behaved exactly like D modules do, is this wrong?
You write:
module urho3d.core;
extern(C++, Urho3D) {
extern(C++, Core) {
class Context {}
}
}
You can use this like:
module foo;
import urho3d.core;
Context context; // unqualified just works
urho3d.core.Context c2; // module-qualified; just works
Urho3D.Core.Context c3; // C++ namespaces work too
urho3d.core.Urho3D.Core.Context c4; // My eyes!
You might sometimes want to use the C++ namespacess when you think it's
clearer, but in general you want to ignore them. That's because, if you
import two modules that both use the same C++ namespace, you get
ambiguous lookup results.
When you go to perform a lookup, let's say for Urho3D.Engine.Engine, the
compiler sees an `Urho3D` symbol in module urho3d.core. But it also sees
an `Urho3D` symbol in module urho3d.engine. That's ambiguous, so it
issues a compilation error.
This might lead you to conclude that you need to give your D modules
different names than the C++ namespaces they wrap, to avoid ambiguities.
But it does in fact work as you expect. I believe the D module is given
priority -- if you're so inclined, you can write such things as
`std.vector.std.vector v` and it just works.
The more I look into this, the more I'm impressed by how well it works.
I'm kind of surprised that people are insisting on complaining that
there's an additional namespace that's trivial to ignore, and they want
not to have the option of using C++ namespaces. I mean, that might be a
*little* cleaner, but it's certainly not where I'd make my Waterloo.
