4 ms·
CZMQ is a library of around 30K lines of code. The Scalable C book is in many ways a guide to using that library in real projects. Of course every programmer d
by PieterH 11y ago
CZMQ is a library of around 30K lines of code. The Scalable C book is in many ways a guide to using that library in real projects.
Of course every programmer develops their own dialects, just as every writer has their own voice. C is however a small language and if you stay away from weird macro magic, any well-written C code is mutually intelligible to other C programmers. Whereas with C++, dialects can have so little overlap they are not mutually intelligible.
FWIW neither of the fragments is safe if you are sharing state between threads. In practice we do not share objects between threads, and each object holds its own state, and thus our C code is 100% thread safe and reentrant.
- jasode 11y ago>The Scalable C book is in many ways a guide to using that library in real projects. I'm not criticizing the book or czmq. I'm sure it's a fine library. I just found your characterizations of C++ to be strange. For example: ">, any well-written C code is mutually intelligible to other C programmers." If you're going to qualify C code with "well-written" to help make your point then can't the same qualification be applied to C++? If so, it means you believe that there is "well-written C++ code" that is simultaneously unintelligible to other programmers. In your opinion, what would be an example of that? (E.g. If you can point to github of unintelligible but well-written C++ source code.) And your other statement: >, because your particular dialects of C++ tend to isolate you. I don't know if CryEngine and Unreal game engines are well-written C++ but they seem attract developers. There's also the scuba diving app[1] written in C++ that also has Linus (who you already know hates C++) modifying the source code. I contend there are bigger factors than C++ dialects causing isolation. The C++ ABI may be more isolating than the C ABI because of C++ name mangling incompatibilities. But I don't see how the C++ dialects (of well-written code) are isolating. [1]https://github.com/torvalds/subsurface https://github.com/torvalds/subsurface
- microcolonel 11y agoGiven the sheer breadth of approaches and features in C++, any one codebase will only touch some of it. Inevitably this means that if you get used to C++ in one project, you will have more difficulty moving to projects using a different subset.
- PieterH 11y agoSince you ask, I'll admit it: I enjoy trolling C++ users because the language has so often thought of itself as superior to C. Beating on the language always gets lots of discussion going, which is fun. I've nothing against the language, or any other language, as such. Good tools, in the hands of good developers.
- unscaled 11y agoI find it the other way around. It's usually C hackers who tend to describe C++ as the devil incarnate. C++ developers tend to be more pragmatic - we'd happily write in C if necessary, we just find it limited. And since C++ is almost a superset of C, there's rarely any need to use it.
- tamana 11y agoThank you your honesty. Now, C++ developers can stop trying to have a productive conversation with yoir new generation of hipster C programmers crafting smal-batch artisinal bytes, and get back to getting work done.
- felixgallo 11y agoFrom experience, both unreal and cryengine are perfect examples of Pieter's point. They're large codebase with archaeological layers of many different c++ styles and paradigms.
- jasode 11y ago>perfect examples of Pieter's point. Please consider the precise argument I was responding to. Pieter's point is a stronger statement than just the existence of "different styles". (Every significant codebase by multiple people has multiple styles -- e.g. see Linux distribution.) He was stating that there was a cause and effect such that the different styles ("dialects") cause "isolation". If so, it means Apple's Swift compiler written in C++ on github[1] should be getting near zero forks and pull requests. In his theory, Chris Lattner and his dialect of C++ should be "isolated". It's also possibly unintelligible C++ (although I haven't looked at it yet). If it was just one of those throwaway sentences to troll people, then fine. My first impression was that he wanted his programming guide to be taken seriously. I enjoy reading C++ criticisms. The criticisms in the C++ FQA by Yossi Kreinin has interesting points. I'd prefer it if the faults of C++ were accompanied by evidence. [1]https://github.com/apple/swift https://github.com/apple/swift
- felixgallo 11y agoYes, like I said, speaking from experience, different C++ code styles and paradigms absolutely do cause isolation. Having to climb yet another mountain in order to be effective on a different codebase in the same language means people don't do it, so they become experts in a single codebase -- isolated.
- unscaled 11y agoI've never really got the "C++ dialects" argument so popular with C enthusiasts. Sure, C++ is several order of magnitudes more complex than C, and this complexity breeds different dialects. But for an experienced C++ programmer, that's a stylistic problem (you generally end up disliking the dialect of about half of the libraries you use), not an intelligibility problem. I've read many libraries, both C and C++, and I've never found C++ libraries particularly hard-to-read. There are a few libraries rife with deep template magic (Boost.MPL et al.) but they are hardly the rule. The real problem with C++, is that truly competent developers are hard to find. I've worked with and interviewed countless C++ developers. Very few used anything from C++11 (except for auto perhaps), and most are essentially program C++ as C with Java-style classes bolted on top. Templates are few and far between, and manual memory management abounds. So these incompetent C++ developers you hear about in Linus' frequent rants? They're mainly C developers who learned some C++. Good C++ developers write cleaner code that's easier to read compared to C, but it takes more time to train one than it takes to train a C developers. But if you only care about fast developer training, Java, or even better, Go are much better choices than C.
- pekk 11y agoIf one particular language suffers so much from all its programmers being incompetent, it should raise the question of what about the language makes it so hard. You can't reasonably dispute that C++ is a gigantic language full of optional features. To be competent with C++, you really have to learn which features to use or not. It's too bad that not everybody agrees on which features to use! Blaming outgroup C developers for everything is a cop-out.
- unscaled 11y agoOh, if it was only so easy! There are many other languages which abound with incompetent programmers. Even an atrociously simple languages had many incompetent programmers over the years. On the other hand, there don't seem to be a lot of incompetent Haskell programmers. It's usually practical reasons which determine the influx of newbies with no previous experience and little incentive to learn to a language. Popularity-wise, C++ was the Java of the 90s, and many programmers came during that time and don't want to learn anything new. Many other programmers are essentially not willing to learn C++ features beyond the features they're already comfortable with. "Which features not to use" is another myth propagated by professional C++-bashers. There are very few features in C++ that you shouldn't use, and most of them are officially deprecated parts of the standard library. The real problem is developers who refuse to learn templates, because "void pointers are simpler", or reject std::array, because it's fancy C+11 stuff and writing "char myArray[100]" is much shorter than "std:array<char, 100> myArray;". They then go on to forget std::array ever exist, and complain that vector is too inefficient, so they're going to use C arrays all the way. If you're willing to use all these newfangled features like closures, initializer lists, 1-part for or constexprs, its' very hard to shoot yourself in the foot. It's very easy to shoot yourself in the foot by using raw C arrays or manual malloc/free though.