- Overview
-
Table of Contents
- Special Member Functions: Constructors, Destructors, and the Assignment Operator
- Operator Overloading
- Memory Management
- Templates
- Namespaces
- Time and Date Library
- Streams
- Object-Oriented Programming and Design Principles
- The Standard Template Library (STL) and Generic Programming
- Exception Handling
- Runtime Type Information (RTTI)
- Signal Processing
- Creating Persistent Objects
- Bit Fields
- New Cast Operators
- Environment Variables
- Variadic Functions
- Pointers to Functions
- Function Objects
- Pointers to Members
- Lock Files
- Design Patterns
- Dynamic Linking
- Tips and Techniques
- Five Things You Need to Know About C++11 Unions
- A Tour of C99
- A Tour of C1X
- C++0X: The New Face of Standard C++
- C++0x Concurrency
- The Reflecting Circle
- We Have Mail
-
- C++ Sudoko, or How to Become a Real Hacker
- Member Name Lookup
- An Operating Overloading Question
- Living Without New
- Solving a Mysterious Compilation Error
- A Magical printf() Call or a Buggy Mess?
- Submitting a Library to the Standards Committee
- The Portable Datatypes Dilemma
- Can I Assign Pointers to a Specific Memory Address?
- Header File Naming Issues
- The Linkage of Enumerations
- unique_ptr And The Deprecation Of auto_ptr
- A const Member Function Conundrum
- Bugzilla
- A Response to Linus Torvalds' C++ Diatribe
- Pseudo Constructor Initializers
- Comment Terminators and The Keyword int
- Questions About enum Types
- Pointers to volatile
- Warnings on const Declarations
- Questions About inline
- The Costs of Virtual Functions
- More on Rvalue References
- Questions About Virtual Functions and Copy Constructor Calls
- More on Functions and the Safety of Union-Based Cast
- More on Default Initialization
- Overriding new and delete
- Are Constructors the Bane of Real-Time Programming?
- What is Required of a Move Constructor
- What's RAII All About?
- An auto_ptr Conundrum
- Where Has <tt>std::array</tt> Gone?
- Why Comparison Operators Are Declared Friends
- Detecting Memory Leaks to Improve Performance
- What Does Alignment Have to Do with Pointers?
- A Question about Class Member Initializers
- A Static Anonymous Structs Conundrum
- The Soapbox
- Numeric Types and Arithmetic
- Careers
- Locales and Internationalization
A Response to Linus Torvalds' C++ Diatribe
Last updated Jan 1, 2003.
In what has become a cult show, Linus Torvalds attacks C++ every now and then, repeating more or less the same claims. In his latest diatribe he said: "C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C."
Here's Steven Dewhurst's reply to Linus Torvalds' criticism:
I think it's only fair to point out that Linus' diatribe is more than a year old, and he has spoken in more measured and printable tones elsewhere about the same subject. Less excusable, however, is that he makes the claim that C++ cannot be used in resource-constrained areas with nothing but anecdotal evidence to support his claim. Linus has done good work and has earned his soap box, but he also has a professional obligation to make sense while he’s holding forth. (For those who follow such things, this is an instance of Gotcha #12, “Adolescent Behavior,” from C++ Gotchas.)
The argument that abstraction and efficiency are mutually-exclusive or that they're mutually exclusive in the context of C++ is demonstrably false. Lately, much of my work involves writing embedded code in C++ with heavy use of inheritance and templates, and the results have been more than promising. The resultant code is typically smaller and faster than the equivalent (well-written) C code provided by the board's manufacturer, and has the significant advantage of being usable by a developer who is not expert in the minutia of the board's design. Unlike Linus, I haven't written a commercial OS, but I have written a policy-based, pre-emptive tasker in C++. It occupies just 3k of RAM and is pretty zippy in addition to being easy to understand, customize, and maintain. Just to annoy people like Linus, I've also used typelist meta-algorithms to generate exception handlers with identical efficiency to hand-coded C. In a number of recent talks given at the Embedded Systems conferences, I've shown that commonly-criticized C++ language features can significantly outperform the C analogs. As an old-school, Bell Labs C hacker I've nothing against C. But C++ provides tools and capabilities that are hard to come by in C, and often make it easier for a competent C++ programmer to produce cleaner and typically smaller and faster code than the C equivalent.
Regarding competence, Linus’s implied argument that C++ attracts bad programmers the way other things attract flies is, in spite of the effective metaphor, both unfair and a little over the top. Inexperienced or incompetent programmers have been lured into writing bad code in other languages as well; I've inherited my share of poorly designed and rendered C. There's no question that C++ is a significantly larger and more complex language than C, and a competent C++ programmer should be familiar with many more design styles (including, among others, that "idiotic 'object model' crap") than a competent C programmer. Wider experience with different design approaches and coding idioms is an advantage if the programmer actually has more than a passing understanding of the techniques. Problems typically arise when teams of competent C programmers are thrown onto a C++ project without adequate preparation simply because C++ syntax looks something like C syntax. The results are usually about the same as you’d get by throwing the same team into a COBOL project. But you’re not going to catch me criticizing COBOL. That’s Linus’s job.
