Slashdot Mirror
An Interview With C++ Creator Bjarne Stroustrup
DevTool writes "Bjarne Stroustrup talks about the imminent C++0x standard and the forthcoming features it brings, the difficulties of standardizing programming languages in general, the calculated risks that the standards committee can afford to take with new features, and even his own New Year's resolutions."
I always preferred this interview with Bjarne Stroustrup.
(Yes, I know it's not real, but...)
> Games developers, a few corporate app maintainers and...
Most Mozilla project applications including Firefox.. Pretty much all of KDE and some of GNOME. WebKit. Google Chrome. Opera. A good chunk of OpenOffice. Most Adobe applications. Most Microsoft desktop applications including Internet Explorer. CUPS. The Qt toolkit and pretty much everything that uses it. MySQL. Autodesk Maya. Winamp.
I wouldn't say a *few* corporate apps are written in C++, I'd say pretty much every major desktop app that's undergone a major re-write within the last two decades is probably C++.
My Other Computer Is A Data General Nova III.
It seems to me that most tasks that seem good for C++ would be better handled using a mix of an easier-to-program language (Ruby, Python, heck even lisp or smalltalk or anything else) with C extensions.
IMHO C++ seems not very good at very low-level programming; since with C++ it's not always obvious what a compiler might want to do with '+' thanks to operator overloading and rather convoluted implicit casting rules. In C you're using a pretty good tool for low-level programmings (especially with a dialect where you can sneak in a few assembly calls where you need to). In Ruby you're using a reasonably nice and efficient to develop in OO language. With the incredible ease of writing C extensions for Ruby, it's easy to use the best tool for each part of the job you're doing. The only compelling reason to use C++ I can think of is if some political policy forces you to use a single language for an entire project; and then I guess C++ not quite as clunky as java or c#.
( though I'm kinda repeating myself - a longer rant I made on slashdot about the pains of C++ years ago is here http://slashdot.org/comments.pl?sid=100202&cid=8540772 . An even more condemning annoyance about C++ is that thanks to so many convoluted tricks in the language, most people who claim C++ knowledge don't actually know it, as evidenced by the comments in that old thread )
I disagree on several points. C is great for low level programming, but many times you want to use OO rather than procedural programming. C++ allows you to do exactly the same low level programming you can do in C (including inline-assembler if needed), but also offers the ability to design in OO. I can't think of a good reason not to use C++ rather than C unless it is a simple monolithic (preferably small) project. Mixing languages brings a whole other set of headaches (including staffing issues). Ruby, Python or other languages are fine and have their place, but I can't imagine using them for systems level programming anymore than I would use C++ to build a web application. Languages like Python, Ruby, (errr.. LISP? - there is considerable debate over whether LISP is even a true "programming language" but rather an alternate implementation of a Turing machine, but I digress) are orders of a magnitude too slow to be used as systems programming languages.
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
I used to be a huge C++ fan, though that has waned over the years as I've used better-designed languages and have also seen other people struggle with C++'s testier features.
That said -- I'd still take C++ over plain C for essentially anything in a heartbeat. (Basically the only exception would be stuff like microcontroller programming or other environments where there isn't really a good C++ compiler.) RAII alone is enough to seal that deal.
I don't buy most of the arguments of C over C++. For instance, take your statement that "IMHO C++ seems not very good at very low-level programming; since with C++ it's not always obvious what a compiler might want to do with '+' thanks to operator overloading and rather convoluted implicit casting rules."
But with modern compilers, I feel it's already very not obvious what the compiler is going to do with your code. What function calls are inlined? What loops are unrolled? For what I think is a reasonably dramatic example of this, take the following snippet:
and compile with optimization on. Look at the resulting assembly. There's no branch! (I'm assuming a variant of x86 or x64 here.)
If you're on a 64-bit system with GCC you'll probably see a cmov (conditional move) instruction, which kind of makes sense. But you don't even need that instruction to be available for it to omit an actual control-flow jump. Recompile with -m32 and look at the assembly again. Much longer, but still no branch. Instead, it uses one of the setxx instructions (setg in my case) and a bit of bit twiddling.
In my opinion, today's optimizers make the generated code so far removed from what you type into your editor that saying "+ can do anything!" is a drop in the bucket.
So you have to be paranoid and check the class definition just in case.
So I have two responses to your general comment, though they are related.
You don't need to check the class definition at all -- you just need to know that one of the operands is an object. That's all. IMO, that's the only* difference between an overloaded operator call and a normal function call.
Once you're at that point, I don't see any difference between calling the function "+" and calling the function "doSomethingSimple". If you're paranoid enough about the class defining "+" in a way that will cause it to open sockets and thus you have to check the class definition to see if it does, you should be equally paranoid that "doSomethingSimple" will do the same thing and you have to check the class definition anyway.
The second part of my response is this: why do you CARE what "+" does internally? I can think of two reasons.
First, because you're concerned about efficiency. I've already said why I think this is a red herring, especially because I suspect most overloaded operator functions will be inlined to something efficient in general other way.
The second reason is because you want to know whether "+" is a good name for that function. But again I don't see how this differs from normal functions. If I call a function add and write a.add(b) instead of a + b, why are you more suspicious about the latter? I can come up with bad names without operator overloading plenty easily enough. Hell, I come up with bad function names for my non-overloaded functions far more often than bad function "names" for my operators. (And that even neglects the personal opinion that the normal convention of a.add(b) for a + b -- e.g. like what's used in Java's complex class -- feels wrong to me. a.add(b) feels way more like a += b than a + b to me. But again -- this isn't the fault of Java not supporting operator overloading per se, but rather the fault of Sun's function naming.)
* Okay, there is one other difference. Operator overloading is cool and tempting to use. It invites abuse way more than function naming does. But some high-profile cases aside (in particular, the proposal to overload the comma operator or whatever it was to load containers, a la Vector v = 4, 5, 6, 7, 8; or something), it certainly seems to me that, in practice, programmers are actually able to hold their tongues pretty well. Strangely enough, the biggest exception to this, I feel, is the bitshift overloading in iostreams. And IMO, that's easy enough to learn and brings about enough benefits (I/O type safety, non-repetition of type information, and extensibility vs a printf-style interface, and way less syntactic overhead vs repeated function calls) that it's probably the best solution even though it's not entirely satisfactory.