On Mon, Jul 29, 2013 at 4:50 AM, David Jeske <[email protected]> wrote:
> 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. > C++ is pretty much impossible for dynamic libraries. There are too many ways to hit the fragile base class problem, and too many things you can do where the language definition doesn't specify what happens. For example: if you add a virtual method at the end of a leaf class, where does it appear in the VTable? If it doesn't appear at the end, you have broken link compatibiilty. And if that class isn't final, you will of course have broken link compatibility on your client's classes. > 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. > Yes. Having run compiler groups, having been part of the team that designed the ELF-based DLL mechanism, and having been the guy who designed the position-independent code standard for the MIPS 32 architecture ABI, I can confirm that this process is an unmitigated disaster. :-) > The common villain here is the fragile-base-class problem, though I see > templates and class-size fragility issues as being equally related. > Templates are effectively inlining, so that isn't as much as an issue. The more subtle problem is version drift when old templates have been expanded in the client and new ones have been introduced in the DLL. The same thing can happen with inlining; there are cases where you don't *want* the compiler to inline because you want to be able to change implementation. But when the compiler sees a small procedure visible in a class, it tends to get aggressive about that procedure. Not sure what you mean by class size fragility. > Also sometimes cited as C++ issues are exceptions and > argument-type-overload name-mangling, though I wonder if the latter is a > true issue. > The mangling issue is ancient history. The early rules were a pain, but the later (cfront 2.2 and later) rules for extern "C" are reasonable and sane. Exceptions *are* a problem when you mix C++ with non-C++ code and you compile the C code with a non-C++ compiler. The exception chain itself can be maintained pretty easily across compilers, but there's no good way to hook the exception chain for use in C code. Meanwhile, there has been enough drift away from C that it's now hard to write code that compiles correctly in both the C and C++ languages. > 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. > And EROS - we got at least a 20% speedup by switching to C in Coyotos, mainly because the requirements of exception support can't be turned off while remaining within the language, and the setup for exceptions we never took was expensive. > 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. > Yes. And that's something that LLVM is very good at. > > 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. > Good point and good issue. Can you re-state this in a new discussion thread on this list, please? > 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. > Actually, C structures are *much* better than C++ classes, because the consequences of adding fields to the shape of the structure are well defined and visible to the programmer. Yes, it's possible to have problems, but it's also possible to avoid them. In C++, it's not possible to avoid them in some cases. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
