5 ms·

One of the advantages C has over C++ here is that the addition of templates in C++ makes this kind of encapsulation more difficult. See the proliferation of hea

One of the advantages C has over C++ here is that the addition of templates in C++ makes this kind of encapsulation more difficult. See the proliferation of header-only libraries where nearly everything is templatized, as well as the pimpl idiom. You still get some encapsulation in the form of private, but with "C-style" encapsulation, if the header file doesn't change and the source files implementing what's declared in that header don't change, then none of the files need to be recompiled when rebuilding. This makes recompiling much faster. Of course, you could do much the same thing if you didn't use templates in C++, or if you were very disciplined and limited with your use of templates, but this seems to go against the grain of how I've seen C++ used.

cozzyd 3y ago
It is different, but provides much better encapsulation. Keeping ABI compatibility is much easier this way.
pjmlp 3y ago
No longer the case since C++20 modules.
- sfpotter 3y ago
  Thanks for the downvote...? Not sure what the point of that was. I haven't used C++ much since modules were introduced. From doing some quick reading, it seems unclear whether they significantly improve compilations times in practice. I wasn't able to find anything which addressed how they relate to the ABI... I suspect this is a pretty complex topic. If you have any good references related to either of these points, I'd be very eager to read them. Either way, "C++ with modules" appears to me to be unlikely to clear the bar set by "C with opaque types" (which, for all intents and purposes, can be done in C++) in terms of 1) ABI stability and 2) encapsulation. I consider point (1) to be related to point (2), since details which are leaked into the ABI are not encapsulated.
  - pjmlp 3y ago
    First of all, who told you I downvoted you?!? Importing the whole standard library as defined by C++23 import std; is quicker than doing a plain #include <iostream>, as shared per Microsoft employees in some talk they have done regarding upcoming C++23 support. Unfortunely I can't remeber which one it was, but someone else can glady share the link. Second by having template details marked as private on the module metadata, that isn't directly exposed to consumers. As for the ABI specifically, that is compiler dependent anyway.

cozzyd 3y ago

It is different, but provides much better encapsulation. Keeping ABI compatibility is much easier this way.

pjmlp 3y ago

No longer the case since C++20 modules.

sfpotter 3y ago
Thanks for the downvote...? Not sure what the point of that was. I haven't used C++ much since modules were introduced. From doing some quick reading, it seems unclear whether they significantly improve compilations times in practice. I wasn't able to find anything which addressed how they relate to the ABI... I suspect this is a pretty complex topic. If you have any good references related to either of these points, I'd be very eager to read them. Either way, "C++ with modules" appears to me to be unlikely to clear the bar set by "C with opaque types" (which, for all intents and purposes, can be done in C++) in terms of 1) ABI stability and 2) encapsulation. I consider point (1) to be related to point (2), since details which are leaked into the ABI are not encapsulated.
- pjmlp 3y ago
  First of all, who told you I downvoted you?!? Importing the whole standard library as defined by C++23 import std; is quicker than doing a plain #include <iostream>, as shared per Microsoft employees in some talk they have done regarding upcoming C++23 support. Unfortunely I can't remeber which one it was, but someone else can glady share the link. Second by having template details marked as private on the module metadata, that isn't directly exposed to consumers. As for the ABI specifically, that is compiler dependent anyway.