So you say FLOSS is responsible that the late 90s/early 2000s C++ hype slowly died off?
> trying to fix the security inconveniences caused by this manifesto.
And you believe those projects chose C, solely because some random GNU document suggested they do?
If that document didn't exist they would have chosen what? C++98? Java? Ada?
Had GNU/Linux not taken off, in the alternative universe from Windows, BeOS, Mac OS, OS/2, commercial UNIX (remember Motif++ and CORBA?) would kept writing the software in C++, instead of caring about creating FOSS stuff in C.
GNOME vs KDE is a good example of that schism and language wars.
Namely:
- proper string and vector types (most compilers allow to enable bounds checking anyway)
- stronger rules for type conversions
- reference types for parameters
- better tooling for immutable data structures
- memory allocation primitives instead of getting sizeof wrong to malloc()
- collection library instead of reinventing the wheel in each project
- RAII
- smart pointers
- templates instead of error prone macros
- namespacing (usefull in large scale projects with prefix tricks)
string & vector types: STL, 1998 type conversion operators: 1998. mutable keyword: 1998. collection library: STL, 1998. smart pointers: STL, auto_ptr<> in C++98
I'd argue that without STL & C++98, C++ would've languished even longer. And with STL, it still took another 5 years for the compilers to be good enough.
This is under-stated, IMO. It wasn't really until 2004 or even later that we had high-quality support for C++98 in GCC. LLVM wasn't available, yet. Heaven help you if you wanted to develop in C++ on OSX, since Apple's packaging of GCC was a total disaster. Step zero for developing C++ on OSX was "install GCC from FSF sources" for many years.
Even MSVC support was lagging. It wasn't until the Microsoft tools leadership got involved with C++11 that MSVC took standard support seriously. They were already prioritizing .NET in that timeframe.
Meanwhile, the big open-source desktop C++ libraries (Qt and WxWindows) still don't fully take advantage of the types and features in the standard library in 2021.
If you were developing Mac programs in C++ back then, you were probably using Metrowerks CodeWarrior.
Of course not. C++ and libraries don't go along nicely. STL is not really useful for cross boundary interop due the fact that C++ ABI is not stable.
Shipping libraries that leak STL types all over the place will only give you headache.
And no, that is not correct.
Mac OS was a mix of Object Pascal (originally created by Apple), Assembly and C++.
Windows (32 bit variants) and OS/2 userspace has always been a mix of C and C++.
BeOS userspace was C++.
Symbian was full C++, including the kernel by the way.
That doesn't ring true at all.
Object Pascal was a rather short-lived project at Apple. It was only seriously used for the MacApp framework -- which was a separate product sold to application developers, not part of the core OS or development tools -- and was abandoned entirely during the PowerPC transition. Later versions of MacApp used C++.
The bits of source code I've seen for System 7 were primarily C and assembly, with some older code in (non-object) Pascal. I don't recall seeing any C++.
% find ~/Downloads/System\ 7.1\ Source/ -type f -print0 | xargs -0 -n 1 basename | cut -d. -f 2- | tr '[a-z]' '[A-Z]' | sort | uniq -c | sort -rn | head -20
869 A
308 H
189 C
162 P
85 R
69 MAKE
31 M.A
28 O
11 RSRC
11 AII
...The choice was protracted language wankery with continuous (wrong) declarations of "Soon, the compiler will make it fast enough", or actually shipping software.
The balance started tipping in the early to mid-2000s. You could, if you were very careful, write decent-sized systems with good performance in C++ at that point, and the abstractions were starting to be worth it.
And I say that as somebody who enjoys C++, and has written code in it since the late 80s. Yes, on cfront. "Horses for course" always has been, and always will be, the major driver for language adoption. That particular horse wasn't ready in the 90s.
As have I, and I say you don't seem to know what you are talking about. I've been involved in writing very large Unix and Windows applications in the 1990s (starting in the late 80s), and have had no problems that you mention.