5 ms·

Would you say that the predominance of C++ rather than C in FLOSS would have a net positive result?

pjmlp 5y ago
Yes, because while it isn't fullproof due to copy-paste compatibility with C89, at least it offers better tooling for safer coding, provided one doesn't code "C with C++ compiler". 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)
- mcguire 5y ago
  I also have a copy of P. J. Plauger's Draft Standard C++ Library.
- groby_b 5y ago
  A large number of those came only usefully into existence in 1998, with C++98 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.
  - brandmeyer 5y ago
    > 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.
    - DerekL 5y ago
      > Heaven help you if you wanted to develop in C++ on OS X, since Apple's packaging of GCC was a total disaster. If you were developing Mac programs in C++ back then, you were probably using Metrowerks CodeWarrior.
    - for_xyz 5y ago
      > 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. 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.

Yes, because while it isn't fullproof due to copy-paste compatibility with C89, at least it offers better tooling for safer coding, provided one doesn't code "C with C++ compiler". 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)

mcguire 5y ago
I also have a copy of P. J. Plauger's Draft Standard C++ Library.
groby_b 5y ago
A large number of those came only usefully into existence in 1998, with C++98 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.
- brandmeyer 5y ago
  > 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.
  - DerekL 5y ago
    > Heaven help you if you wanted to develop in C++ on OS X, since Apple's packaging of GCC was a total disaster. If you were developing Mac programs in C++ back then, you were probably using Metrowerks CodeWarrior.
  - for_xyz 5y ago
    > 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. 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.