Perils of C++ debugging: Petrifying functions(yosefk.com)
yosefk.com
Perils of C++ debugging: Petrifying functions
http://www.yosefk.com/blog/the-c-sucks-series-petrifying-functions.html
5 comments
You may have missed the paragraph about books pretending C++ is high level. My understanding is that he hates that, not necessarily C++ itself. I see this rant as yet another proof that C++ is as low level as C.
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 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 low-level C++ calling functions from Fortran and doing all sorts of magic to do out-of-core matrix calculations.
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.
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.
Generic code with all my objects cleaning up after themselves.
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? :)
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? :)
With proper overloads you can easily track your memory usage or even which instances are leaked.
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.
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.
Generally not a problem if you don't use much multi-inheritance. Making your objects exception-safe will have lots of benefits -- and it's exceptions that are far more likely to be causing leaks in your code than destructor-order issues. Your mileage may vary.
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.
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, the API of these auto clean up objects is high level. Now how high level is the implementation? If you wrote it yourself (you sound like you did), and the abstraction has few or no leak, I bet you had to write insanely low level code to achieve that.
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.
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.
I should get back into the habit of reading comments first. It would have saved a lot of time in this case.
He may be using the wrong debugger. When I recreate and run his project in Visual Studio, I get this error:
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.
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 wonder here if the problem is really just the small default stack size on Linux. In fact, why is the stack limited to 8MB by default?
(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).
(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).
8 MB is also the default on Mac OS X. That's for the main thread -- for other threads (at least those created by the standard pthread mechanism), it's only 512 kB:
http://developer.apple.com/mac/library/qa/qa2005/qa1419.html
http://developer.apple.com/mac/library/qa/qa2005/qa1419.html
Could be worse on windows (even 64bit) it defaults to 1MB and a spacious 4MB on Itanium.
As a long time C++ programmer is very much appreciate expert C++ advice, even if it comes from someone who hates C++.
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.
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.
This reminds me of a guy I knew who spent all the time working on his car. All day long, and all night, he'd be outside underneath banging away at something.
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.
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.
It's not just the articles on his blog; yosefk is also the author of the C++ FQA Lite: http://yosefk.com/c++fqa/
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.)
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.)
Yes I thought this author was a rerun -- I remember his FQA being posted here a year or so ago.
The opposite of love is not hate; it's ambivalence. So he must really still carry a torch for the old girl.
The opposite of love is not hate; it's ambivalence. So he must really still carry a torch for the old girl.
From a different post: "...because that would offend C++, The Hate Of My Life, who does have an ANSI standard. Relax, darling. It’s you, and only you, that I truly hate. The others mean nothing to me."
http://www.yosefk.com/blog/python-teaching-kids-and-biting-b...
http://www.yosefk.com/blog/python-teaching-kids-and-biting-b...
I think it's less a case of the complaining hobbyist and more a case of Stockholm Syndrome in a guy who debugs other people's C++ for a living because the people who write the code are smart enough not to learn how to debug it. See: http://www.yosefk.com/blog/the-cardinal-programming-jokes.ht... wherein plumber jokes involving copious amounts of excrement are made.
ambivalence != indifference
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.