4 ms·
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. i will never understand why
by zabzonk 3y ago
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.
i will never understand why C programmers get so upset about C++. of course, the latest revisions of C introduce some new features not in C++, but nothing really major. if you want good type checking, compile your C code with C++, and fix all the type errors you will get.
- pjmlp 3y agoPetzold did the same on his highly acclaimed book for Windows 3.x book, also with a note on the preface regarding type safety. Likewise, Microsoft introduced windowsx.h header file, to improve type safety while using C for Windows 3.x applications.
- zabzonk 3y ago> Petzold did the same on his highly acclaimed book takes me back. i thought it was crap. i used to work at The Instruction Set (one of UK's biggest tech training companies at the time) and everyone hated the Windows/C course based on Petzold. my boss came up to me (somehow I was the windows guy in a unix company) and said "we need a new windows course" and me said "OK, i need a framemaker license and to work at home for a week" - worked out great. this was early 90s, i suppose?
- pjmlp 3y agoAround 1991. I mostly programmed on Windows 3.x with TPW and TC++, alongside OWL. Those nice Borland manuals. For me, in what concerns C programming for Windows 3.x, the "Programmer's introduction to Windows 3.1" was a much better book. Mainly due to its coverage of windowsx and message macros. It's on the Internet Archive. https://archive.org/details/programmersintro00myer https://archive.org/details/programmersintro00myer
- jstimpfle 3y ago> 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. [0] https://www.sandordargo.com/blog/2022/02/16/deducing-this-cpp23 https://www.sandordargo.com/blog/2022/02/16/deducing-this-cp... . There is also a youtube video somewhere.
- synergy20 3y agoI dreamed about a simplified c++, that is better/safer than c but much simpler than existing c++, call it c+, a subset c++ that enhances c but not bringing in all those c++ complexities that I 99% do not need in daily coding.
- c_crank 3y agoThere is such a language called D.
- synergy20 3y agosadly no time to pick a new languages these days. will just cherry pick c++ features and build my own subset of it and call it c+ myself, this seems the quickest way to get daily coding done fast for me.
- gnuvince 3y agoThere are many new languages that describe themselves as taking C, adding some good stuff (slices, defer), removing some of the bad stuff (textual includes) and adding some of their own spice. One might have the right mix of features for you: Zig, Odin, C3, Hare, Jai.
- flohofwoe 3y ago> compile your C code with C++ You're most likely not aware (as most C++ coders unfortunately), but this advice is useless today since it's not possible to compile current-time C code with a C++ compiler, the two languages have diverged too much since around the mid-90's. A C++ compiler only accepts a "common C/C++ subset", but this subset hasn't been updated to include C features that had been added after ca 1995. A better advice is to simply use the highest warning level and enable warnings-as-errors, this gives you mostly the same type checking as in C++ (minus the void* conversions, but that's how it should be since a void* is basically an "any*").