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.
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.
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? :)
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.
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.
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.
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.
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:
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 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.
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.)
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."
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.
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.