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.

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?

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.

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.

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. :(

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.

There may be reasons to want to mix manual and automatic memory management. If you want to do that, there are language that support it. Like D.

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.

I asked why one should mix management of resources, and you answer that one should mix management of resources. But I still don't know why?

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.

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.

Which part of it do you not like?

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.

Don't the boost guys say that now C++ is the most powerful programming language?

source?

http://librelist.com/browser//mongrel2/2010/7/15/c-verses-c+...

I'm still looking for the part where he doesn't understand how const _works_.

"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.