Christopher Bazley <[email protected]> writes: > I haven't worked on libgomp, but I agree with Martin's points. > > A lot of compilers can plausibly support modern C that will never > support modern C++.
libgomp is a GCC runtime library. The only compiler of concern is GCC. > Modern C offers features for convenience (e.g. auto) and macro-based > polymorphism (e.g. _Generic). Subtype polymorphism is more limited > than in C++ but still achievable with a reasonable degree of type > safety. Yet, it offers no destructors, and no move semantics, which are arguably the most important features of C++11 and onwards. I'd trade _Generic for those two, and make it out of the deal like a bandit. > The issue with malloc seems to me like a canary in the coal mine. I > don't know whether libgomp makes significant use of callback functions > and event handlers, but they are likely to suffer from similar > issues. If the return type of malloc is perceived to be a problem, > then it is trivial to write a wrapper macro, e.g. I don't see what issue that is. Previously, allocation and initialization were separate. They aren't in C++. I don't see how that could apply to either callbacks or event handlers. (Note that every single instance of an allocation in libgomp falls under the case of trivial initialization by merit of being a C codebase, and ergo, even the initially-proposed mechanical conversion of allocation sites is not incorrect, just presumably inconsistent with newer code) > C projects 'upgraded' to C++ can end up worse than reasonable code > written from scratch according to good idioms of either language, due > to: Yes, this isn't surprising. That's exactly why I was arguing not to do mechanical explicit void* casts in the cases where memcpy is immediately followed by initialization. The instances where allocating uninitialized memory is genuinely useful are in the tiny minority, but they do exist in libgomp. These need to still call malloc explicitly with a computed size, as in C. There are also a number of useful flexible array members, but for these, each such type can provide an allocation-and-construction helper. > - C++'s overly strict type rules concerning void *. Without care, C++'s type > system has the ironic effect of making code *less* type-safe. (For the same > reason that it would be less type-safe for MyPy to require explicit > conversion of 'Any' to some other type.) ? Those rules aren't overly strict. I don't follow how this analogy with 'Any' demonstrates a lowering of type safety. > - C++ constructors being unable to return a failure indication, and the > gymnastics required to work around that without using exceptions (leading to > many identically-named construction helpers). I've been writing C++ in places where exceptions would be inconvenient for many years now, and this is a fairly infrequent requirement IME. It will be fine. > - Erasure of designated initialisers that were vital for keeping the code > readable and maintainable (by preventing definitions, for example array > initialisers and enumerations, from diverging). Designated initializers exist in C++. > - Gratuitous loss of the ability to find method definitions and usages using > simple tools like 'grep'. (I do not mean gratuitous as a perjorative but in > the specific sense that some useful patterns require subtype polymorphism, > in > which case the equivalent C code would have the same issue, but most code > does not.) There's no C pattern that is impossible in C++. There's certainly nothing that requires dynamic dispatch that wouldn't require a (hand-rolled) vtable in C. Do note, however, that such a table exists in libgomp already: https://gcc.gnu.org/cgit/gcc/tree/libgomp/libgomp.h#n1391 > As I said, I'm not familiar with libgomp, so I have no idea how much > it might benefit in areas where C++ truly does excel, such as object > lifetime management. In my experience, few C projects have complex > object lifetimes (by design), but maybe libgomp is one of them. Trivial objects still benefit from destructors. unique_ptr is a distilled example. > Lastly, some C programmers are put off contributing to C++ > codebases. I don't know how common the converse is. Given that gcc is already in C++, it seems that that bridge was burned. Have a lovely day. -- Arsen Arsenović
signature.asc
Description: PGP signature
