extern(C++, ns)

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Sat Jan 2 21:40:23 PST 2016


On 1/2/2016 8:54 PM, Manu via Digitalmars-d wrote:
> C++ namespacing is causing me endless, and I mean *endless* trouble.
> This idea that we express the C++ namespace hierarchy in D is the main problem.
> I don't think C++ namespaces should interfere with D scoping rules, they should
> be purely for mangling.
> It creates a whole bundle of edge cases which either don't have work arounds, or
> REALLY awkward workarounds which typically have a heavy impact on all the
> regular D code that the C++ code interacts with.
>
> Not least of which is that C++ namespaces usually span the entire project, and
> in D a C++ namespace can only appear in one module ever.
> Declaring symbols with the same C++ namespace in different modules leads to
> multiple definition errors, and if you are super-careful to avoid those, you
> gain name resolution issues in it's place.

That works the same as in C++. Don't define the same symbol in the same C++ 
namespace in multiple modules. It doesn't work in C++, and doesn't work in D for 
exactly the same reason.


> It is also very awkward that a C++ namespace can't be the same as a top level
> package name. My top level package is named the same as one of my C++
> namespaces... what do I do? It gets ugly real fast.
>
> The main problem extends from this situation:
>
> module x.y;
>
> extern(C++, ns) struct Y {}
>
>
> module ns.m;
>
> import x.y; // fail, the c++ namespace is already present (top level module)

Doesn't fail when I try it.

> import x.y : ns.Y; // fail, '.' can't appear here

Right, this syntax only works for module scope declarations. Y is not module scope.

You can do:

     import x.y : ns;

> import x.y : Y; // fail, not found

Again, Y is not module scope.

> // This **sometimes** works,

sometimes?

> and it's very brittle

??

> static import x.y;
> alias Y = x.y.Y;

Nothing wrong with that.

> Thing is, I'm not declaring a C++ object, I'm declaring a D object,  the only
> thing being that struct's take care to maintain common binary layout, and
> functions just mangle like C++ so that my code links. I'm in D, I'm declaring my
> stuff in the D module where it should be scoped, and where other D code should
> expect to find it. I don't see any point in building the C++ hierarchy in this
> space. C++ namespace rules are incompatible with D; you can litter them through
> C++ code, and add new symbols to C++ namespaces from anywhere...

You can do that in D as well, as long as you follow the One Definition Rule, 
which you have to with C++ code anyway.

> this is
> fundamentally incompatible with D, and no further reasoning should be required
> to conclude that it can't be reproduced, so it should be for mangling purposes only.

I guarantee you that if we'd implemented it that way, you'd have a long litany 
of complaints about that, because the compiler could not distinguish Y from ns.Y.

> I have spent **days**, actually, weeks of my free time trying to make my tiny
> bit of code build, and it's just nothing but trouble after trouble. I have
> completely restructured my code at least 3 times to try and find a way to make
> it fit together in a way that's both practical and works, but I just can't. It
> always hits some brick wall somewhere.
>
> extern(C++, NS) looks okay in isolated tests/experiments, but try and actually
> use it, and you will become very frustrated.
>
> Please, fix this. I'm almost done. I'm really struggling to keep this dream alive.

I do not understand what difficulty you are having with this.


More information about the Digitalmars-d mailing list