On 12/14/2011 1:47 PM, Dejan Lekic wrote: As subject says. I am pretty much happy with the current C++ support. The only thing I need is to be able to call functions from namespace(s). Any plans to add this feature? Walter's response: I hadn't planned to, but it's a good idea. I suggest adding it as an enhancement request on bugzilla. I forgot about it, but lately I need namespace support again, so I am filing this feature request here. :) This is, I believe, a very important feature as many people deal with C++ libraries lately.
I already looked into this. Could have it done by Monday.
How do you plan to do it on win32?
(In reply to comment #2) > How do you plan to do it on win32? https://en.wikipedia.org/wiki/Visual_C%2B%2B_name_mangling
(In reply to comment #3) > (In reply to comment #2) > > How do you plan to do it on win32? > > https://en.wikipedia.org/wiki/Visual_C%2B%2B_name_mangling I mean, how do you plan to implement this given that on win32, C++ name mangling is done by the dmc backend code rather than in the frontend like all other platforms.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > How do you plan to do it on win32? > > > > https://en.wikipedia.org/wiki/Visual_C%2B%2B_name_mangling > > I mean, how do you plan to implement this given that on win32, C++ name > mangling is done by the dmc backend code rather than in the frontend like all > other platforms. Oh, you're way ahead on me on that one. I had not noticed the difference. But since the code is available for both, it should be possible to do, one way or the other. Any ideas? Or perhaps it's time to make win32 more like win64. And get rid of optlink in the process :) What we have to decide first, though, is how to declare the namespaces in D. UDA? I don't think we should be using the module name, since that's completely unrelated in C++ and D. Declaring functions as statics in a struct could work, but would conflict with actual nested methods.
(In reply to comment #5) > > Oh, you're way ahead on me on that one. I had not noticed the difference. But > since the code is available for both, it should be possible to do, one way or > the other. Any ideas? > https://github.com/D-Programming-Language/dmd/pull/2074 Or possibly, adapting the code in there to use the existing mangling interface, and not rely on https://github.com/D-Programming-Language/dmd/pull/2356 > Or perhaps it's time to make win32 more like win64. And get rid of optlink in > the process :) > Yeah I'd stay away from that mess. > What we have to decide first, though, is how to declare the namespaces in D. > UDA? > > I don't think we should be using the module name, since that's completely > unrelated in C++ and D. Declaring functions as statics in a struct could work, > but would conflict with actual nested methods. pragma(cpp_namespace, "blah") ... pragma(cpp_namespace, "blah", "nested") ... or maybe pragma(cpp_namespace, ["blah", "nested"]) ...
Isn't a C++ namespace only a mangle thing? In that case can't we just use pragma(mangle) and create a library function which helps making it a bit more high level: pragam(managle, namespace("foo::bar")) void x ();
(In reply to comment #7) > Isn't a C++ namespace only a mangle thing? In that case can't we just use > pragma(mangle) and create a library function which helps making it a bit more > high level: > > pragam(managle, namespace("foo::bar")) void x (); We would have to mangle in the function name and type as well. Not really something you want to do manually.
(In reply to comment #8) > We would have to mangle in the function name and type as well. Not really > something you want to do manually. No, right. This doesn't work either due to forward reference: pragma(mangle, namespace!("bar", foo)) void foo (); Is this something we want to, and can, make work? I'm just trying to come up with a solution that doesn't require a compiler change or a change that can be applied more generally.
(In reply to comment #9) > (In reply to comment #8) > > > We would have to mangle in the function name and type as well. Not really > > something you want to do manually. > > No, right. This doesn't work either due to forward reference: > > pragma(mangle, namespace!("bar", foo)) void foo (); > > Is this something we want to, and can, make work? I'm just trying to come up > with a solution that doesn't require a compiler change or a change that can be > applied more generally. > pragma(mangle, namespace!("bar", "foo", void function())) extern(C++) void foo (); The way to do it is to generate both the pragma(mangle) args and the function signature from the same source. But really, pragma(mangle) is too blunt a tool for this. Especially considering you'd usually want to apply the namespace to a whole bunch of declarations. It might also be worth considering the behavior of pragma(cpp_namespace, "foo") pragma(cpp_namespace, "bar") extern(C++) void baz();
Guess we could use extern(DMC++) vs extern(C++) etc.
(In reply to comment #5) > What we have to decide first, though, is how to declare the namespaces in D. > UDA? I like the UDA idea, if a library solution cannot work. It will look quite similar to C++: @namespace("foo") { @namespace("bar") { void x (); } } It can also support a less verbose syntax for nested namespaces: @namespace("foo::bar") void x (); Or @namespace("foo", "bar") void x (); Or implement AST macros and do it with library code :)
https://github.com/D-Programming-Language/dmd/pull/2767 Using @namespace, like so: struct namespace{string s;} extern(C++): void noattrib(int); @namespace("test") { void attrib(T); struct T; } Would personally love to have "::" support as well, but should we allow @namespace("::") to reset? Might get too complicated. Current system maps nicely to C++.
Resolving because of DIP 61 pull request: https://github.com/D-Programming-Language/dmd/pull/3517