"There appear to be a lot of good rants against C++....Are there any good passionate pro C++ versus C arguments?"
By definition, the people who write the "entertaining" rants against C++ have an axe to grind. The people who like C++ just silently use it, and feel no need to write advocacy blog posts for the language. Even if they were to blog about it, it would be about as compelling as someone advocating for their favorite brand of screwdriver. Like it or not, C++ is the incumbent, and it's neither interesting nor fun to read someone advocating for the status quo.
Whenever you find yourself arriving at an opinion about a programming language solely from rants that you read on some dude's blog, please keep in mind that you're probably being most heavily influenced by the very people least qualified to teach you anything useful about the language. The internet is filled with useful articles about C++, but you don't remember those. You remember that Zed Shaw couldn't figure out how const works in C++, and once wrote a funny email about it.
Indeed. At my last job, working on trading software, we had around 35 maths or physics PhDs working on a C++ application. A few had personal blogs (cats, children, steam engines, etc) but as far as I am aware no-one there argued on the Internet about which language was best. C++ just doesn't attract self-publicists the way Ruby seems to.
> C++ just doesn't attract self-publicists the way Ruby seems to.
That's a cheap shot ... Linus Tolvards is definitely not the Ruby-type.
And his arguments are sound ... for system programming, C is a much better language because it's simpler, lacks magic, making the pieces of code easier to understand without the bigger context, and it's more portable.
And for application-level programming, why would you chose a language without a garbage-collector?
Perhaps you need to run deterministically without a stop-the-world garbage collector? A) the world is bigger than simple web applications and B) some of us have been doing this for a long time.
I wasn't talking about web applications, and modern garbage collectors are not stop-the-world.
Not to mention ... stop-the-world garbage collectors have a good reason for doing what they do. They are defragmenting the memory. You get that for free, when in C++ you would have to deal with hell if your app is doing lots of allocations ... see the shit the Firefox devs had to go through to alleviate the problems of heap fragmentation, and its still a problem.
Ah, but what, you're using both managed code (C#) and unmanaged code (C++) in the same address space, doing memory intensive work using third party proprietary C++ code that does lots of small allocations?
In 32-bit land, it's welcome to OutOfMemoryException because managed code can't allocate a big enough chunk when returning to C#.
No free lunch :)
Either recycle processes often or reserve big enough contiguous chunks in managed code before calling out to the bad C++ code, no amount of good citizenship in managed code will stop the poorly written native code from fragmenting the hell out of your address space.
I've experienced problems with java's concurrent mark and sweep collector. It will stop the world, two times, but two much shorter times than a non-concurrent mark and sweep. So it is definitely an improvement in the duration of the stop-the-world.
The problem tends to be that you need to tune it, and even as you have tuned it, you can not promise that under special condition it will fall back to a more primitive collector since the optimality it was tuned for doesn't hold anymore.
I would never argue giving up garbage collection entirely because of these failure scenarios. I would much rather look at moving some critical part of the code out to a language with manual allocation, and let it perform the latency-sensitive bits.
Another mid-ground is to have separate isolate processes (heaps really) that can be stop-the-world collected without blocking each other. Erlang makes great use of this to accomplish "soft realtime", among other things.
Side rant: it's part of the reason that my Palm Pre will sometimes just hang for a second at the worst times, such as when I go to answer the phone. :(
A simple mark & sweep or stop & copy GC. Collectors which are incremental (work in small steps, not one full pass at a time) and/or generational (using several smaller generations, which are collected individually) break up GC pauses into something less disruptive.
For a good overview, read "Uniprocessor Garbage Collection Techniques" by Paul Wilson (check google scholar). Richard Jones's _Garbage Collection: Algorithms for Automatic Dynamic Memory Management_ is more in depth.
Not necessarily allocating very large chunks in bulk but umm... Allocating nodes for a million nodes of a graph and subsequently processing them. Java JVM fragments memory heavily.
En
> And for application-level programming, why would you chose a language without a garbage-collector?
Because your code uses some finite resources other than memory, and you don't want the ability to forget to release said resources when you're done with them and they go out of scope.
Why should memory management related to managing other resources. Anyway, you might be interested in The Haskell Disciplined Disciple Compiler (http://www.haskell.org/haskellwiki/DDC) which lets you statically encode resource management rules. (And of course spots garbage collection for memory.)
Your objects contain/use various resources, such as memory, file descriptors, mutexes, etc. The way to reclaim any of these is to destroy the object, which lets you reclaim all of them. So memory management is very much tied to other resource management, since they both involve the same thing (deciding when to destroy objects you no longer need). Unfortunately not all resources can be collected equally lazily, so memory-centric GC schemes that ignore the requirements of other resources tend to get in the way (and make you do using(){...} or try/finally to make sure your files are closed, instead of allowing for RAII).
How to unmix: Just e.g. close your files explicitly, but let the memory of the data structures that represent your files be garbage collected normally.
For patterns of usage similar to RAII, Common Lisp uses unwind-protect. I already mentioned Disciplined Disciple Compiler that extends Haskell to give static guarantees for following certain rules for resource management.
Why would you bother: RAII only covers some cases for resource management, and most garbage collectors can take an arbitrary long time to collect an object that's no longer reachable. Which is fine for memory, because memory is fungible, but the attached resources, say mutexen, are not necessarily fungible.
For some concrete examples of the above: WebKit, Chromium, Gecko, and V8 are all C++.
My impression is that there is a very high startup cost with C++ to getting it working on the platforms you want to support and picking the subset that isn't going to screw you. Once you get over the hurdle, the improved memory management (I agree with the post Zed is ranting in response to) starts to pay dividends.
V8 is ringing endorsement for V8. It is just a well-designed JavaScript virtual machine. It's performant because it compiles JavaScript to native code and uses generational garbase collection.
Good advice generally, but what axes do Zed and Linus have to grind? Sounds like both just think C++ enables too much complexity to be worth the benefits.
It's actually possible to make C++ nice, the Grace library is wonderful. If I ever have to C++ again I'm totally grabbing it and using it. The Grace value types and type safe format operations are just the best thing ever.
My problem though is it's not the right tool for the job. Simply having access to C level APIs doesn't instantly mean your language is awesome at making servers and operating systems. Especially if that same language can't quite figure out what the hell really happens on a copy, or during an exception, or can't make decent strings and data buffers.
I figure they have the axe of "I used this for a while, and really grew to hate it when I compared it to these other things I used" to grind. Sometimes the technologies you use just make you want to get something off your chest, you know?
"You'll find crap in C++ like const *const char &, and hell if anyone knows what that really means since even though the pointer to a const to a const reference is consted to hell and back, oh look you can still increment it."
I'm still looking for the part where he doesn't understand how const _works_.
"const *const char &" is not valid C++ syntax, so I'm pretty sure you can't increment it. Therefore, anyone saying you can increment it doesn't understand it. QED.
Oh, you have to read that in the voice of The Comic Book Guy. Then it's fucking hilarious. Here try it:
"You sthee const const &const char[const ] is the proper way to make a thruly safe reference to a conthst char array conthst pointer conthst."
See, prime comedy gold there.
Also, 'cause you guys think the internet should be nothing but a massive academic white paper curated by Knuth, so any amount of hyperbole sends you into a literalism hissy fit.
He mocks that you can attach const nearly anywhere in c++ and it seems to do something different. (Note: This is a generalization, an important aspect of many jokes)
By definition, the people who write the "entertaining" rants against C++ have an axe to grind. The people who like C++ just silently use it, and feel no need to write advocacy blog posts for the language. Even if they were to blog about it, it would be about as compelling as someone advocating for their favorite brand of screwdriver. Like it or not, C++ is the incumbent, and it's neither interesting nor fun to read someone advocating for the status quo.
Whenever you find yourself arriving at an opinion about a programming language solely from rants that you read on some dude's blog, please keep in mind that you're probably being most heavily influenced by the very people least qualified to teach you anything useful about the language. The internet is filled with useful articles about C++, but you don't remember those. You remember that Zed Shaw couldn't figure out how const works in C++, and once wrote a funny email about it.