>The more C++ you know the worse you become at working with others. First, because your particular dialects of C++ tend to isolate you.

So why is using something non-standard and non-universal like not perceived as a "dialect" of C?[1] Any non-trivial source codebase beyond "printf("hello world")" will be a "dialect" of the programmer(s). When looking at the C source files of Linux kernel, Redis, and SQLite, etc, the syntax patterns, helper macros, string manipulations, etc do not look the same.

Also the author's example of,

  for (i = List.begin (); i != List.end (); ++i) 
    cout << *i << " ";
is not the same semantics as:

  char *fruit = (char *) zlist_first (list);
  while (fruit) {
      printf ("%s ", fruit);
      fruit = (char *) zlist_next (list);
  }
The C++ loop is multithread safe. The C version is not. For the zlist_next() to work, the "list" data structure needs to maintain mutable state in between subsequent calls. (Think of how something like strtok() works by mutating the string).

[1]possibly because Pieter Hintjens is the programmer & CEO behind ZeroMQ and czmq.h. Therefore, it doesn't feel like a dialect to him?

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.

>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

From 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.

>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