On Sunday, July 29, 2018 6:10:01 AM MDT kinke via Digitalmars-d wrote: > On Sunday, 29 July 2018 at 11:03:43 UTC, Jonathan M Davis wrote: > > I guess that the argument at that point is that you would have > > to put them in separate D modules, just like you would if they > > were extern(D) functions. > > Yep, that'd sound acceptable to me, implying that > > ``` > extern(C++, cppns) { void foo(); } > void foo(); > ``` > > wouldn't work anymore, and particularly, this neither: > > ``` > extern(C++, cppns) > { > extern(C++, nested) { void foo(); } > void foo(); > } > ``` > > so that a straight C++ namespace => D module hierarchy mapping > would probably be required in the general case: > > ``` > // cppns/package.d > module cppns; > extern(C++, cppns) { void foo(); } > > // cppns/nested/package.d > module cppns.nested; > extern(C++, cppns) extern(C++, nested) { void foo(); } > ```
Honestly, I'd expecting folks doing bindings for anything serious would be matching the layout of the C++ header files being translated. It becomes difficult to maintain bindings when their layout doesn't match the original files. Most of druntime's C bindings match the layout of the C headers that they're translating so that it's straightforward to find them (the primary exception being that OS-specific symbols from a standard header end up in a different file, which can be confusing and maybe shouldn't have been done, but those files follow the same layout - just in a different hierarchy under the OS's name). Anyone who didn't at least nominally make the layouts match would almost certainly run into maintenance problems in the long run. - Jonathan M Davis