I'm not sure why I would ever dick around with C++ lambdas when I could instead just write in C and a "real" high level language, like Python, Lisp, or Ruby.
Comparing C plus Python to C++ doesn't make any sense. The comparison would be C plus Python vs C++ plus Python.
The C++ solution would most likely be shorter, more flexible, and more secure. Personally, I fail to understand why anyone would choose to write new C over C++.
The C++ version will absolutely not be more secure; we find just as many vulnerabilities in "modern" template-y C++ code as we do in straight up C. We know how to secure C code, even if we are bad at it. Nobody knows anything about C++ security.
I have difficulty handling the complexity of typical C code due to the lack of abstraction. C always winds up with huge functions and lots of hard to grasp state up in your face. C++ gives you way more opportunities to hide away complexity.
C always winds up with huge functions and lots of hard to grasp state up in your face.
That's something I've never found to be the case. Most of my C functions are 5-15 lines long. Anything more than 20 lines long is a candidate for refactoring - the unit tests will tell you if you've broken anything.
Think of it like this: Would you rather have an operating system that has a bunch of little ads in the corner by the clock that are periodically "hidden" under a chevron, or would you rather that the crap wasn't there in the first place?
Modern C++ almost eliminates manual memory management. STL along with tr1::shared_ptr makes memory management almost as easy as with scripting languages. This alone trounces C.
Pass a shared pointer to a library that doesn't know how to handle it (read: almost any third-party library). Now you've got two pointers to the same block of memory under two different memory management regimes. What could possibly go wrong?
You can't accidentally pass a shared pointer to a library function in C++. You'd get a compiler error. Then you'd pass the pointer within the smart pointer and make sure the case was handled appropriately. It's not hard and it's definitely still worth it to liberally use shared_ptr.
You can't "accidentally" do it; it's just that the only way to actually do it in practice is fundamentally unsafe. "It's not hard"? You know what else isn't hard? Making sure you don't treat an integer as signed in one place and unsigned in another. There's $1.5Bn USD of "not hard", right there.
There's no law that states that you have to litter your code with calls to malloc()/free() when writing C.
If reference counting won't do, there's more than one garbage collector freely available, and they're not all that hard to implement from first principles if the mood takes you.
If you're peppering your code with malloc/free, it has nothing to do with not "writing your own memory management"--your code is just badly designed to begin with.
Dude...seriously: there are garbage collectors for C++. They're not exclusive to C!
Moreover, the C++ garbage collectors are pretty darned easy to use, given that the language builds in support for custom allocators, overriding new/delete, etc.
The fact that it is trivially simple to garbage collect both C and C++ code neutralizes the "automatic memory management" advantage, dubious as it was, from C++.
Not really. One reason that you infrequently see C++ programs using garbage collection, is because the language includes some nice tools that mitigate many of the pain points that drive people to use GC in the first place.
If you're using C++ as its own language, you get many of the nice things that come with memory management in dynamic languages, but you don't have to pay for it at runtime (the inclusion of shared_ptr in C++0x is a great example of this, actually). If you merely use C++ as "C with classes" (I'm not saying that you do this...just generally), then you don't see this benefit of the language.
What are you talking about? auto_ptr? shared_ptr? You don't pay for these if you don't use them; the language gives you the option of trading safety for speed. That's what I meant when I said that you don't have to pay for the features.
In any case, the reference-counting used by the safe pointers is probably an order of magnitude less heavy than a garbage collector. Even if you use them, you aren't paying that much...
You don't think it's nitpicky to suggest that C++ gives you automatic memory "for free", as long as you don't ever use it?
Garbage collection is not an "order of magnitude" more heavy than reference counting, and there's more than one axis to measure memory management on --- in fact, there are several axes for allocation transactions alone.
Just as importantly, if you go to Google Code Search and randomly select ten C++ projects that (a) have more than 10,000 lines of ".cpp" and ".i" file code and (b) use shared_ptr, I'm betting you're going to find that 8 of them rewrote some of the memory allocator for performance reasons. All the fancy template BS in the world doesn't save you from the fact that "new" is just "malloc", and there's no one allocator design that works for every program.
I don't know, but when I want nice memory management in C code (and usually, if I'm writing something in C, it's at least partly because I care a lot about how memory is managed), I just use Boehm GC.
Okay, so you've introduce a third-party dependency. Again, how much work are you willing to do to duplicate a language feature that C++ gives you for free?
Oh give me a break. Until the new standard hit, practically everything that made C++ bearable was a third-party dep on Boost. And the difference between Boost and Boehm GC is, I don't have to read documentation or even change my code to use Boehm.
"Avoiding third party deps". The dev team that embraced that standard sure sounds like a blast to work on. The wheel I can't wait to reinvent? Zlib.
> practically everything that made C++ bearable was a third-party dep on Boost
For what it's worth, pretty much all good C++ devs I know are getting nauseous at any mentioning of Boost .. with "passionate hatred" being a more accurate description. Very professional (older) crowd, responsible for some very notable and large-scale projects.
In general, C++ is too feature-full to ensure any sort of consistency of coding and design styles between any two C++ developers. Some use it as beefed up C, others - strictly as OO language. Former will never be pleased with the code produced by latter, and vice versa. Boost only amplifies these differences, so it's really not a big surprise that it is despised in certain C++ circles.
Comparing the most famous garbage collection library of all time to the output of a standards body is not a stretch, and now we're into "some third party deps are good --- the ones that support my argument --- and some are bad --- the ones that support yours". I'm happy to consider us stalemated and move on.
