> they should simply use c++, like k&r did to compile their example code in their 2nd ed - see preface to book if you don't believe.
So what? And GCC allegedly has been C++ for many years. Please take a look at the repo and tell me why this means anything (besides language wars being a waste of time).
My personal experience with C++ is that I seem to always end up peeling off my nice abstractions again later. Most of what it offers hasn't stuck for me, at least for systems programming. There's a lot of bad C code I've had to work on over the years, but overzealously architected C++ codebases take the crown for inflicting the most pain for sure. One recent experience was when I replaced 4 files and 200 lines of C++ classes with 4 lines of straight C code. Not even a function was necessary. And that was one of the less bad experiences because it was actually possible to fix.
In my most recent attempt to be open-minded about it I've ended up keeping a few short methods, which can be nice for code brevity at the call site, and there is less of a tax about having to come up with naming schemes. But I have otherwise found classes (and in particular methods) to be painful for two reasons: All the procedures operating on the class have to be declared in the class (or as static methods in a friend class, but then they have to be declared there). This includes private methods and is just one more level of annoyance for a small (and debatable) syntactic convenience. It's pretty f***ing bad to have to turn implementation details to the outside (it extends transitively to implementation types used in your private methods etc.), and that is a big reason why C++ projects have infamously longer compile times compared to C projects.
Another problem with methods is that it seems you can't define them as having "static" linkage, at least not with MSVC. I suppose this can increase link times and prevent the compiler from making some optimizations.
One other thing I did was trying to buy more in to RAII, for example doing ref-counting in an automated way. It's another area where I feel I've lost a lot of control over what happens (it's hard to get it right), and my codebase is slowly deteriorating.
Another big problem that I personally see is implicit "this". C++ would already be a much better language without this. It's a bad tradeoff IMO (and Python was right to make it explicit), I can't see a benefit of not typing "this->". It is misleading while reading, and frequently having to change method parameter names just to be able to access both is a real annoyance. (From which code style rules like "m_" prefix arise, which typically don't get followed 100% -- so you'll see locals with m_ and members without it -- and which add two more characters, making the implicit this even more useless).
After a few months I am back to writing simple structs with none of this counter-productive (at least for small teams) access protection, and simple plain functions.
That's only scratching the surface of C++ (it's only about "C with classes" so far). I do know "modern C++" to a degree, and when digging deeper into the trends from the last 1-2 decades it gets much worse. I've been following what the C++ committee is up to these days and it seems they are stubbornly penny-wise but pound-foolish. One recent example -- they have now improved the type inference of "this" !!with an added new syntax!! [0] so you can have "easier" CRTP patterns. Does anyone but the most extreme freaks still understand what actually happens there or is the C++ audience mostly an army of copy&paste coders?
As a proficient C programmer, it's so much easier to be annoyed about most of C++'s features, because they break so quickly when put under stress, and just being a bit more explicit with C-style code seems to often lead to more maintainable code and actually not that much more code, sometimes even less (not having to deal with all the crazy abstractions).
That all said, throwing in the occasional templated function or class for good measure can be incredibly powerful, much better than dozens or hundreds of lines of C macro generator hacks. It can be useful also when working with IDEs. But it's a slippery slope and mastering it is hard.
my point was that k&r used c++ for it superior type checking (and because the C++ compiler could actually compile C89 code, which no commercial compuilers at the time could) - obviously in a book about C they did not use C++ features. so i am not sure what you are going on about here.
i learned assembler and fortran, then abandoned them for C, and then abondoned C for C++. i did all that progression because it self-evidentially made me more productive.
Couldn't care less about the type checking differences (apart from using abstract classes with virtual methods, but that's not C syntax), they're quite small and the C++ way is in fact an annoyance e.g. when interfacing with straightforward void pointer APIs. That reminds me of enum class, another feature that brings something nice to the table (properly scoped enum names for better IDE completion) but is almost made unusable by the fact that they can't be easily used with bitwise operators.
The thing about C++ is that many of its features start with a good intention, but most of them are so specific that they have to go down one almost arbitrary route (non-orthogonal decisions, like enum class introducing at least 3 changes at once) and pessimize the other use cases. Good luck refactoring your codebase when you realize you have to change your approach and it's no longer supported by any kind of specialized syntax. That's a problem that C mostly doesn't have -- most of its features are needed when programming a computer, and they're minimal and orthogonal, with few ways to paint yourself in a corner.
well, they are different (and better). but if you want to use old C-style enums, go right ahead - you can do that too. i don't see why you are complaining about a new feature that in no way clashes with an old one.
I do not actually think they are better. They are broken for most of my use cases. Most of the time I'm better off using traditional enums with explicit sizes (a C++ extension that I deem sane), optionally wrapped in a namespace.
The mere existence of all those features costs a lot of time just to understand and navigate them. They can diminish productivity. C++ is a huge language. It has tons of features that suck up a lot of time until you understand the space where the features can be used to good effect.
And "good effect" often means just writing the same thing in fewer characters, or a little more type-safe (which often wouldn't be needed if the design were sane).
And if the requirements slightly change and that good feature breaks, enjoy your rewrite! Or add another set of abstractions or even macros to work around the breakage -- like MS did in case of enum class bitwise operators for example.
That's why many people restrict themselves to C entirely -- no time to waste on finding out why C++ features X, Y, and Z all don't work for the given problem. Time could be better spent than with obsessing over all the ways in which an arbitrary set of features can be abused to write the implementation in fewer lines of code, meanwhile making it harder to read & write. Just think about the algorithm & the data layout, and bang out the code.
So what? And GCC allegedly has been C++ for many years. Please take a look at the repo and tell me why this means anything (besides language wars being a waste of time).
My personal experience with C++ is that I seem to always end up peeling off my nice abstractions again later. Most of what it offers hasn't stuck for me, at least for systems programming. There's a lot of bad C code I've had to work on over the years, but overzealously architected C++ codebases take the crown for inflicting the most pain for sure. One recent experience was when I replaced 4 files and 200 lines of C++ classes with 4 lines of straight C code. Not even a function was necessary. And that was one of the less bad experiences because it was actually possible to fix.
In my most recent attempt to be open-minded about it I've ended up keeping a few short methods, which can be nice for code brevity at the call site, and there is less of a tax about having to come up with naming schemes. But I have otherwise found classes (and in particular methods) to be painful for two reasons: All the procedures operating on the class have to be declared in the class (or as static methods in a friend class, but then they have to be declared there). This includes private methods and is just one more level of annoyance for a small (and debatable) syntactic convenience. It's pretty f***ing bad to have to turn implementation details to the outside (it extends transitively to implementation types used in your private methods etc.), and that is a big reason why C++ projects have infamously longer compile times compared to C projects.
Another problem with methods is that it seems you can't define them as having "static" linkage, at least not with MSVC. I suppose this can increase link times and prevent the compiler from making some optimizations.
One other thing I did was trying to buy more in to RAII, for example doing ref-counting in an automated way. It's another area where I feel I've lost a lot of control over what happens (it's hard to get it right), and my codebase is slowly deteriorating.
Another big problem that I personally see is implicit "this". C++ would already be a much better language without this. It's a bad tradeoff IMO (and Python was right to make it explicit), I can't see a benefit of not typing "this->". It is misleading while reading, and frequently having to change method parameter names just to be able to access both is a real annoyance. (From which code style rules like "m_" prefix arise, which typically don't get followed 100% -- so you'll see locals with m_ and members without it -- and which add two more characters, making the implicit this even more useless).
After a few months I am back to writing simple structs with none of this counter-productive (at least for small teams) access protection, and simple plain functions.
That's only scratching the surface of C++ (it's only about "C with classes" so far). I do know "modern C++" to a degree, and when digging deeper into the trends from the last 1-2 decades it gets much worse. I've been following what the C++ committee is up to these days and it seems they are stubbornly penny-wise but pound-foolish. One recent example -- they have now improved the type inference of "this" !!with an added new syntax!! [0] so you can have "easier" CRTP patterns. Does anyone but the most extreme freaks still understand what actually happens there or is the C++ audience mostly an army of copy&paste coders?
As a proficient C programmer, it's so much easier to be annoyed about most of C++'s features, because they break so quickly when put under stress, and just being a bit more explicit with C-style code seems to often lead to more maintainable code and actually not that much more code, sometimes even less (not having to deal with all the crazy abstractions).
That all said, throwing in the occasional templated function or class for good measure can be incredibly powerful, much better than dozens or hundreds of lines of C macro generator hacks. It can be useful also when working with IDEs. But it's a slippery slope and mastering it is hard.
[0] https://www.sandordargo.com/blog/2022/02/16/deducing-this-cp... . There is also a youtube video somewhere.