Slashdot Mirror
Bjarne Stroustrup Reveals All On C++
An anonymous reader writes "Bjarne Stroustrup, the creative force behind one of the most widely used and successful programming languages — C++ — is featured in an in-depth 8-page interview where he reveals everything programmers and software engineers should know about C++; its history, what it was intended to do, where it is at now, and of course what all good code-writers should think about when using the language he created."
C++ is a language of a million gotchas. The moment I start having to think about implementation detail and I'm not writing an operating system or compiler, I know I'm using the wrong language.
The pun seems to be that KDE isn't structured, efficient, portable or serious, despite being written in C++. I can't blame you for missing it, or finding it not funny.
Stoustrup probably means the binary still runs on the now antiquated system it was originally compiled for. I very much doubt he means that the 20 year old source code still compiles with a modern compiler, as the language has changed way too much. So, Stoustrup's probably being a little bit disingenuous as usual.
What are you smoking?
Which means some PHB swallowed Microsoft's .NET sales lines, not that native code is in decline.
Think what you want, if that extends to the belief that kernels, device drivers or any serious (non-research) systems work is going to be deployed as memory managed JIT'd bytecode -- you're a fool. Performance optimizations are still inline ASM, put that in your "managed code" pipe and smoke it!
If the messages are the same, no one has any reason to see both, so scoring one out of the default view is the Right Thing. If you're pathetic enough to care about karma and this happens so often that it even matters, complain to the admins that the author of a redundant comment hasn't done anything wrong.
...it's largely a waste of time. The author spends an inordinate amount of time complaining that C++ prefers compile-time overhead to run-time overhead, and has no understanding that C++ is designed to have no unnecessary performance penalty relative to C. It would be nice if he did, as whatever insights the FQA author has concerning OO languages could be gleaned without wading through a few thousand lines of whining over the lack of things like garbage collection, heap compaction, run time bounds-checking, etc. He also has apparently never heard of Boost.
And in fact, Cfront was a compiler, not just a preprocessor; it was just a compiler that compiled C++ into C.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I'm afraid that web site is one of those things that gets way too much attention in some on-line communities because of its controversial nature.
The reason the two sides are far from equally partisan is that Stroustrup freely admits there is another side to the debate and that C++ has its flaws, and he is making efforts to improve the situation. The FQA, on the other hand, just makes blanket statements like "For example, the lack of garbage collection makes C++ exceptions and operator overloading inherently defective", which simply isn't true (and neither are many of the statements made in the FQA under those particular headings).
If you read the comments the guy who wrote the FQA makes on forums like reddit, as well as throughout the FQA itself, it's pretty obvious that unlike Stroustrup, he has little interest in any balanced discussion on the subject. He's just out to prove the other side wrong — where "wrong" often means "not agreeing with him" — and perhaps, the cynic in me suspects, to make a reputation for himself in the process.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
"The Design and Evolution of C++" by Stroustrup is a must-read if you are interested in why C++ is the way it is.
After reading it, I really hated C++. It's the classic example of a project that gets ruined by too many people working on it, all with their own goals, and the book tells you exactly why this happened. C++ now is a hideously complex monstrosity that is popular because it is all things to all people, not because it is a good language.
Anyway, if you disagree with me, have a look at the book. It is a testament to Stroustrup's objectivity that I came to the conclusion I did, and that you may come to the exact opposite conclusion as me after reading it.
Back that statement up, buddy.
Well, there's no doubt in my mind that C++ is a language design tour de force. The question is whether its design objectives are the right ones.
They were probably the right objectives for the place (Bell Labs) and time (1979) it was conceived.
At the time, computers were inconceivably slow by today's standards. I worked at a small developer that had a very nice AT&T 3B2-400, which had a WE32000 microprocessor, which probably ran at about 10-15MHz; a half dozen programmers shared it.
As for the place, well, it was crawling with C programmers and C libraries, doing rather complex and important systems programming. Compatibility with C and proven C libraries would have been a huge thing.
So, an efficient, object oriented version of C was probably exactly what was needed.
I think that if there was any fault, it was the attempt to meet the goals of efficiency and compatibility with a language that implemented everything that (at the time was thought to be) necessary for programming in an object oriented style. Multiple inheritance carries too much baggage when all you want to do is to guarantee objects have a certain interface. Likewise, I think operator overloading is another example of trying to do too much. Yes, it makes programmer classes "first class citizens", but it really has no demonstrable practical benefit in my opinion. In situations where you need a special purpose language, it's probably better just to create one.
Still, that's hindsight. If you really understand all the things Stroustrup was trying to do, C++ is quite awe inspiring.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Yawn.
If you don't like C++, you probably just don't understand it. Yes, it's a complex language. However, if you use RAII (a fundamental tenant of C++) you will not. leak. memory. ever. Same arguments about C++ are used over and over again by people who don't grok the language. Is it the end-all be-all language? No. But it is darn good at what it does (performance minded system level code) with almost none of the problems C has (memory leaks and weak typing).
I Do C++
Likewise, I think operator overloading is another example of trying to do too much. Yes, it makes programmer classes "first class citizens", but it really has no demonstrable practical benefit in my opinion.
.add(), .subtract(), .multiply(), etc. Once I transliterated a piece of C++ code I had wrote for him and it consumed three times the space and was much less readable due to the nesting of the member functions... being able to use natural math symbols and natural parenthesis makes the math so much more readable, and when 90% of your code is math, you come to appreciate it. I wouldn't have it any other way, at this point.
I write math codes for fun and for a living. I have this discussion on an infrequent basis with a Java buddy of mine. Now granted I'm a dumb mechanical engineer and he's a smart CS major, but when I need some custom math classes that aren't provided by the language (tensors, vectors, Jacobians, Quaternions, etc.) and evaluating long math expressions, it is so much easier to view it using the native math symbols than to nest it all in member functions
Array sizes ARE carried along with arrays.
No, they're only available where the original declaration is visible. Try:
void arraylength(int tab[])
{ printf("size of tab: %d\n",sizeof(tab)); }
which won't work. "sizeof" is not meaningful in that context.
Compare FORTRAN, which allows
SUBROUTINE ARRAYLENGTH(TAB, N)
INT TAB(N) ! conformant array declaration using param
WRITE(*,*) SIZE(TAB) ! write size of array, as known by language
This carries along the info needed for subscript checking. It also encourages users to request the size of an array from a known good source.
The retrofit of conformant arrays into FORTRAN wasn't perfect, but it's ahead of C/C++. ISO Pascal, of course, also has conformant arrays, as do Modula 1/2/3, Ada, and Delphi.
On the other hand, that's not the only natural way to handle the situation you are talking about. Another way is to create a new language. Altogether, I'd rather do the kind of work you're talking about in Matlab or Octave.
I write code for clusters, now specifically CFD. Lots of math, lots of parallel processing. Matlab and Octave isn't gonna cut it, and you really desire the close to the metal aspects of c++.
It may be a narrow range, but there's a lot of people in this narrow range. Specifically, (mechanical/aerospace/etc.) engineers. C++ isn't sexy like Java or Python, but we do a lot of things you just can't do in Python, and can't do fast in Java.
Basically when you have rules you ought to (or "must" unless you want magical bugs) follow that are not enforced by the compiler, the language is flawed. Like when you oveload new but not delete and thus have incompatible memory management. Or you return a reference to a method-local (auto) string object.
It does however give rise to a market for code analysis tools that checks all the stuff the compiler will let you get away with.
But you can save the cost of these tools (or the alternative manual hunt for bugs) by using more modern and productive languages like Java or Ruby, leaving C++ for operating systems and games. And the latter is moving into other lanbguages as well, i.e. Microsofts push for C# in game development, and the widespread use of Python in e.g. EVE Online, ToonTown, Civ IV and other games.
Hex is close enough and less error-prone
When you're actually bitmasking, it's nice to see the bits rather than having to accumulate them in your head.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Probably true. But what does that tell us about general language fitness really since it's equally as easy to hog resources in a language with GC? Database connections for example.
When you absolutely need deterministic release of resources you end up having to approach the problem in a similar fashion to c++ memory management anyway.
Many people believe seem to believe GC allows you to forget about resource management when it doesn't at all.
It's a great tool for a certain class of problems but not a panacea.
i wish i could stop
You might be surprised how many smart people think you're better off actually understanding your code instead of having the computer explain what one path happens to do right now.
That's just the point. Your code isn't the problem for you to understand. In the real world where people have to look at other people's code, you often need all the debugging help you can get.
Stroustrup is being very smug in his response here. He lives in an ivory tower, how much real-world code written by other people (to a deadline or management constraints) has he ever dealt with?
My feeling is, very little..
I also like to remind that generics as now widely used in languages such as Java and C# initially started as templates in C++, only the latter has far better support.
For those who think that garbage collection is the holy grail against leaks in a program, think again. While it may solve memory leaks, it doesn't solve resource leaks (like open connections, file locks,
If you want to know more, I'm always in for a discussion on the subject. Happy to inform.
And what if there's nothing behind the door until it is being opened?
Just a side-note on unit-tests and debuggers (actually off-topic): They're all fine and well, but bugs resulting from bad synchronization (e.g. use of mutex etc) in multithreaded programs will not be detected. Often, if an object is not well synchronized, the chance of having race conditions or lost updates are generally very small and therefor hard to reproduce, but in a production environment they would still come up fairly regularly. E.g. If there's a chance of 1 in a million for something to go wrong due to bad synchronization, you would only encounter it on average every one millionth time you debug your application (=never), while for a computer it's not a big deal to run a piece of code billions of times per day. By definition, unit tests are never run while other threads are touching the same memory because they are meant to test an isolated unit, which boils down to testing them on a single thread, so unit tests will even never spot them.
Don't get me wrong, it's good practice to have unit tests, but there are actually people out there (often IT managers) who imagine that if all code is covered by unit tests that this would guarantee that the program as a whole can't fail so I always like to add this disclaimer when talking about unit-tests or testing in general.
And what if there's nothing behind the door until it is being opened?