Maybe I could say something good about some aspects of their coding style, but that would only distract from my main point that I find it pointless to imitate a C++ API in C, when that API is modeled carefully to take advantage of C++ features, and you lose all of that in C. (Not only that - their C API is designed in a way that adds overhead even where none would be necessary in C, by allocating all structs on the heap.)
There are lots of plain C container libraries which are probably suited better for C, if you really must use C, or prefer C for whatever reason that escapes my imagination.
The 1990's were looking so great for C++ adoption on desktop, we had Mac OS (pity about Object Pascal, but at least there was PowerPlant), OS/2 (with CSet++, and OWL), MS-DOS (with Turbo Vision), Windows (with OWL, VCL, MFC, ATL), BeOS (with its Kits), Epoch/Symbian, Windows CE (with MFC),...
And then rise of FOSS happened, with the original GNU contribution guidelines asserting only C and Lisp as the all mighty languages for the GNU ecosystem to build upon.
When someone queried Harley-Davidson bikers as to why they don't socialize with youngsters who are avid about the latest racing motorcycles, their response was, "Why should we bother? Every year, they have something new.
--
All jokes aside, check out these cool quotes about C++ from Linus Torvalds [0] and Ken Thompson [1] ;)
The UNIX model won over object approaches. And I think there is a reason: The simplicity of flat memory model, C, a unified file interface etc. removes a lot of complexity and allows composition of diverse components to a working system.
Or in other words: If C++ were actually better for engineering large systems, GNU wouldn't have had a chance.
That's funny interpretation, because what is this mysterious "UNIX model" and what does it have to do with implementation language?
Also, C++ used to be "C with classes", but has outgrown this single-paradigm thing quite quickly. I do a lot of C++, but I rarely use inheritance and virtual methods. These are not the features that make C++ worthwile for me.
> The simplicity of flat memory model, [C], a unified file interface
This "unified file interface" is a nice theoretical idea, and it leaks many nice things to the real world, but has nothing to do with the implementation language - quite contrary, it allows many different languages to communicate. Similar with "flat memory model" - you can have either language in segmented memory and flat memory. There used to be "far pointers" in both C and C++, and now they're gone, so what.
> If C++ were actually better for engineering large systems, GNU wouldn't have had a chance.
Oh, if only it were that way, if only inferior engineering systems would just lose and disappear. The sad truth is that survival of a language proves little about quality.
If you believe C is better than C++, fine by me, just opinions. You can say "C++ is bad because it's more complex" or "has too many features", I can understand that, or "C++ is confusing because you can overload operators". My features are your bugs, okay. But I can't comprehend your actual arguments because they are orthogonal to the choice of language.
The comment I was responding to talked about the rise of GNU which allegedly killed better systems that used C++. I argue that GNU won because it was a better system and that it used C and not C++ is one part which made it better. Unified file interfaces are another. You are exactly right that it lets different system communicate, including C++. But this is what makes such interfaces better than - say - an object-oriented interfaces accessed via remote procedure call (and were/are plenty of such systems), which do not interoperate well. Systems built around C++ or with a similar mindset typically tend to have overly complicated interfaces. So yes, one can use simple interfaces with C++. But if you think C++ is a good language, you will likely not define simple interfaces.
From where I am standing, it failed in everything except headless computing, with similar input/output devices as a PDP-11.
If it isn't a server, or a some piece of software running on a smart appliance, it hardly matters how much POSIX it is exposed.
By the way, C++ is also UNIX, born and raised by AT&T in their UNIX labs, it is the main reason why all C compiler vendors adopted it in first place, including Stalmman's GCC, as you should clearly be aware.
You are right that you can build a lot of overly complicated crap on top of simpler systems. Android or the modern web are good examples. But in the long run it is usually not the overly complicated crap that prevails.
History shows otherwise, as proven by any usable modern C compiler is now written in C++ like GNU's compiler, so C++ is definitely better for engineering large sytems, GNU did not had a chance either than accept it and move along into modern times.
> If C++ were actually better for engineering large systems, GNU wouldn't have had a chance.
Unfortunely I won't be around to see this happen, but I bet when the UNIX/Linux/BSD founders generation is gone, other OS pushed by big corps will take its place, maybe even taken by younger devs that took the free beer source code and created their new cool startup with an OS partially taken from it, NeXTSTEP/Solaris style.
Something that is already taking shape on IoT space with all those RTOS using MIT/Apache licenses, and very little POSIX/UNIX on them.
There are lots of plain C container libraries which are probably suited better for C, if you really must use C, or prefer C for whatever reason that escapes my imagination.