Perils of C++ debugging: Petrifying functions
yosefk.com
yosefk.com
He hates C++ and C++ debuggers
Creating huge objects on the stack makes a program dump core due to a stack overflow, depending on the default stack size of the operating system. So a program that used to run OK might suddenly crash after an OS update and the error output wouldn't be very helpful.
I think the sooner we admit this simple fact, the sooner we will be able to see C++ for what it is: a niche language, probably not worth it's huge spec.
I've written high-level C++. Generic code with all my objects cleaning up after themselves.
So my experience is that C++ is a large language that allows programming in many niches.
Are you sure they really cleaned up after themselves, and you don't have a subtle memory leak waiting to happen because of some unnoticed and rare and disastrous problem with the order in which your destructors get called? :)
Then again, I don't mean to trivialize the issue. It can be a real problem. But can you suggest a language that will prevent 100% of subtle memory leaks? I can't think of any. Hell, if you're using Ruby with a pre-1.8 VM, you don't even need to roll your own leaks.
So yes, C++ is low-level (it does after all include C), but it has features to abstract away tedious details — this allows higher level programming but being in control of how the abstractions are implemented, as there are many performance trade-offs in choosing (implementation of) abstractions, and that is what makes C++ such nice language for software where performance is important.
I see only one reason to do that: you need performance so high that no garbage collected language could provide it; and the application is so complex that you have to write high level APIs. Not to mention that your application has to be basically bottleneck-free, or you would have used a garbage collected language, it's FFI, and C/Fortran for the tight loops.
To my eyes, that is a tiny niche. It may even be void. The "pure low level" and "pure high level" niches are both better filled by simpler languages. The "low and high level with bottlenecks" niche can be filled by a combo (a combo is simpler than C++, in my opinion).
Now, there is a huge niche best filled by C++: the use and maintenance of C++ programs. This is my current day job.
Unhandled exception at 0x00b31747 in Bogus.exe: 0xC00000FD: Stack overflow.
The debugger points you to the offending line in a well-commented assembly routine described as ";_chkstk - check stack upon procedure entry".
It's immediately obvious this is a stack overflow, which takes you past the first half of his long article. However the second part of the article is still valid -- you still have to track down which of your objects is the big one.
(I'm no fan of C++, but I suspect a number of languages that allow general stack allocated objects could fail in the same way).
http://developer.apple.com/mac/library/qa/qa2005/qa1419.html
This was great, and I would like to add that any good programmer should know that it is easily possible to run out of stack space, especially with recursion.
I asked him once, "say, you must really like your car"
He said, "Hell no! This POS! Can't stand it. It's a wonder it even runs for one day without my having to tinker with it"
You have to really love something a lot to have an entire series of articles about how bad it is.
And as far as the specifics of this article, it's only so much noise. C++ lets me shoot myself in the foot because different operating systems have different stack sizes and nobody told me about it.
Okay -- welcome to the big leagues, kid, where we play without nets.
He probably hates C++ more than anyone in the universe. (And probably knows more about it than anyone except veteran C++ implementers and committee members.)
The opposite of love is not hate; it's ambivalence. So he must really still carry a torch for the old girl.
http://www.yosefk.com/blog/python-teaching-kids-and-biting-b...