Is there any good reason why C++ namespaces are "closed" in D?
tid3
tide at tide.tide
Sat Aug 4 21:57:32 UTC 2018
On Saturday, 4 August 2018 at 17:54:11 UTC, Jonathan M Davis
wrote:
> On Saturday, August 04, 2018 12:18:21 tide via Digitalmars-d
> wrote:
>> The only person I've seen that wants this is Walter. I haven't
>> seen anyone else show interest in wanting a 1:1 correlation.
>> It's unreasonable, D isn't C++ nor should it be trying to
>> strive to be C++.
>
> In general, it's easier for maintenance if there's a 1:1
> correlation between C/C++ headers and D headers. It makes it
> easier to update the D files, and it makes it easier to find
> where something is in the D translation if you're already
> familiar with the C/C++ version - or if you're reading
> documentation for the C/C++ version and trying to translate
> that into what you need to know to use the D version. For the
> most part, the C bindings in druntime follow the layout of the
> C headers that they correspond to precisely because doing so is
> more maintainable and easier to navigate than if the D modules
> were laid in a hierarchy that followed its own logic instead of
> trying to emulate the layout of the C headers being translated.
> In fact, some of the more annoying issues with the C header
> translations in druntime come from places where the layout of
> the C headers was not quite followed for one reason or another.
>
> So, I'd fully expect most C/C++ binding projects to have a 1:1
> correlation between C/C++ headers and D headers, and I don't
> think that Walter is at all misguided in that respect.
>
> That being said, in most cases, such a 1:1 translation would
> work just fine
> if we had extern(C++, "NS"), and it just affected name
> mangling. There would
> be corner cases where it did not, but they could be worked
> around even if it
> meant that in that particular case, you lost the 1:1
> translation - but as
> Steven pointed out, it actually would be pretty straightforward
> to manually
> add the kind of namespace wrappers that the language currently
> forces on you
> with extern(C++, NS) if we had extern(C++, "NS"). And of
> course, if we
> actually ended up with both extern(C++, "NS"), and extern(C++,
> NS), then you
> could just use the extern(C++, NS) construct in those corner
> cases, though
> ultimately, I think that we'd be better off with just having
> extern(C++, "NS").
>
> So, I don't think that Walter is being misguided here in terms
> of how he expects folks to be translating C++ headers. I just
> think that his concern over some corner cases you get with bad
> C++ code has caused him to make the current solution for
> binding to C++ namespaces more complicated than it needs to be.
> And I don't think that his concerns are misguided either. I
> just think that he's just blowing them out of proportion given
> how easy it would be to work around those issues with the
> solution that Manu wants, whereas the common case suffers with
> the current solution.
>
> - Jonathan M Davis
Alright that's fair but it still isn't ever going to be 1:1. I've
done some stuff with C++ that used the fact that including
headers is just a copy and paste. So I had header files that
didn't have structures defined in them. You would define the
structures before the including the header file so that it could
be used with multiple different headers. There's no way you are
ever going to get a 1:1 mapping of that into D. Let alone
remotely similar, it would have to be completely different.
It's nice to have but you are never going to achieve a complete
1:1 mapping unless you bring all of C++'s features. Even with the
current implementation it doesn't allow multiple namespaces of
the same name in the same D module. Yet Walter is hung up on that
fact of that one edge case.
More information about the Digitalmars-d
mailing list