On Sun, Jul 28, 2013 at 11:50 PM, Ben Kloosterman <[email protected]>wrote:
> And it’s worth noting the lack of penetration of C++ compared to C in this > area when it is really a superset. > IMO, the degree to which C++ has or has not replaced C for systems programming is a topic worth trying to understand better. These days I get pushback on this issue, with systems programmers I know saying C++ effectively has replaced C in most cases. My perception is the same as yours Ben, that for systems-programming such as system-api/DLL/kernel development it really hasn't. Though it is frequently used for static-library and applications development. In the extreme, we can wonder why C++ hasn't completely replaced C, since it is a superset. My long-held belief is that C++'s inability to fully replace C is tied to the way many of it's mechanisms make backward compatible DLL/ABIs too difficult to maintain. The common villain here is the fragile-base-class problem, though I see templates and class-size fragility issues as being equally related. Also sometimes cited as C++ issues are exceptions and argument-type-overload name-mangling, though I wonder if the latter is a true issue. I believe these factors reared themselves in all of the now-dead attempts at C++ for systems-programming.. my favorites being Taligent/Pink and BeOS. Notable C++ successes (such as MSVC++ and Google's C++ codebase), to me appear to succeed because they are effectively whole-program embedded-system compilation, rather than modular systems programming. Other related thoughts: 1) It's important to understand why C++ exceptions are often rejected, (see -fno-execptions and google's style-guide<http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions>) My understanding is that this stems both from difficulty in avoiding memory-leaks while using exceptions, and difficulty in avoiding ABI breaking, in case a previously unknown exception is thrown. Compare this later-case with how trusted the C-standard library would be if it's implementation called exit(1). IMO, to admit exceptions we must have a typesafe exception proposal. I'm not a fan of Java's checked exception system, and years ago wrote a draft concept for a C# checked exception system<http://dj1.willowmail.com/~jeske/unsolicitedDave/csharp_checked_exception_proposal.html>. More recently I've been considering compiler-assisted structured-error-return models, which bears syntactic resemblance to exceptions without the non-local stack-unroll effects. 2) C structures in DLLs also have fragility regarding sizing and offset layout. However, the issues are more direct, easier to avoid, and AFAIK there is no current system runtime which avoids them. In fact, it is not clear we *can* avoid them without a JIT and GC, and since we can't currently meet my systems programming definition with a GC, this issue is currently unavoidable.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
