Sure, C++ has great advantages, but it also great disadvantages.
I use C for many things not because of "macho", but because C is good enough. I can work around the disadvantages using standard techniques. The result is code that is easily FFI'able from any language, quicker to compile, has a smaller footprint, sane error messages, easily debuggable in gdb, etc.
Also, there are some advantages in the abstractions that C encourages you to use. For example, lack of templates pushed C programmers to discover intrusive data structures, and those are better in many ways than templated containers ala STL.
Another example: "virtual" methods may fail to override a base class method if you make a typo - resulting in potentially cryptic bugs. Using a simple macro in C:
I can make vtables that are safer than C++, and require no more boilerplate than C++ code. The compiler will guarantee that I implement all of the required vtable methods.
If I want to get speed via multi-core rather than pure uniprocessor speed, why use C++? I can use Haskell and get much easier and safer parallelism with many other advantages.
I know, but you are the first I've encountered to quantify it.
> The result is code that is easily FFI'able from any language
I agree that this is a big advantage for interoperability. While it's possible to build an interface in C++ with 'extern C', it means maintaining two call APIs rather than one. Still I see this as a current limitation of C++ rather than an advantage of C.
> Using a simple macro in C:
Is generally a pain as the macro is expanded at compile time and causes difficulties debugging. Your point about VTABLEs is well taken however and I have encountered subtle bugs with virtual member functions in C++.
> If I want to get speed via multi-core rather than pure uniprocessor speed, why use C++? I can use Haskell and get much easier and safer parallelism with many other advantages.
You would need to enumerate those advantages for me to answer. Why then wouldn't you use Haskell instead of C?
For the same reasons he listed above, eg you want to use an ffi etc. This is not a temporary issue with c++ as you imply, there are really hard issues about the c++ programming model, eg exceptions and classes, being really hard to interface with other languages that work differently.
The question is not why Haskell not C, sure if you can use Haskell why not, but for most use cases you cannot. But most languages can be used instead of c++, Haskell or Java or whatever, with many advantages.
Sure, C++ has great advantages, but it also great disadvantages.
I use C for many things not because of "macho", but because C is good enough. I can work around the disadvantages using standard techniques. The result is code that is easily FFI'able from any language, quicker to compile, has a smaller footprint, sane error messages, easily debuggable in gdb, etc.
Also, there are some advantages in the abstractions that C encourages you to use. For example, lack of templates pushed C programmers to discover intrusive data structures, and those are better in many ways than templated containers ala STL.
Another example: "virtual" methods may fail to override a base class method if you make a typo - resulting in potentially cryptic bugs. Using a simple macro in C:
I can make vtables that are safer than C++, and require no more boilerplate than C++ code. The compiler will guarantee that I implement all of the required vtable methods.If I want to get speed via multi-core rather than pure uniprocessor speed, why use C++? I can use Haskell and get much easier and safer parallelism with many other advantages.