Simply not true. I use boost heavily on a 120 kloc project, and it takes under a minute to compile everything from scratch. And I use quite a lot of boost features.
You have one large project that compiles quickly and that somehow contradicts me saying that there exist cases where one gets stuck with ridiculously long compile times (attributable to use of complex language features, as opposed to merely the number of tokens in a compilation unit)? If you aren't trolling then I'd love to know how you maintain a 120 K LoC project with such a poor grasp of basic logic.
The cost of the GC is not fixed in any meaning of the word 'fixed'.
Not everything is a real-time app. The odd 1 ms stall is often a very acceptable exchange for time otherwise spent thinking really deeply about memory (and cleaning up after people who misused a smart pointer because he has real problems to deal with). And over a long enough run, the impact of GC is certainly "fixed" at some small percent of overall time. And I've yet to see a live object graph so pathologically bad that GC costs become unbearable that doesn't translate into something with fairly complex lifetime management in C++ (circular references with no clear and obvious owner object are a bitch).
How is that a problem of the language? it's a problem of your development team, not the language. If you have a shitty development team, they can easily mess up a Java program as well.
The set of ways that one can hide a bug in Java (C and C# in my case) is far smaller than that for C++. That might not affect you much when you're writing the code and have it all fresh in your mind, but some of us have to go back and review that code later on.
Occasionally I find things like the wrong operator being called due to an implicit conversion to a compatible type in some silly header intended for some other task, added after the code I'm looking at was written. That shit takes time to find and fix. And neither the coder that wrote the routine, nor the coder that amended the header, nor I are idiots.
And getting bit by some of C++'s more esoteric little rules hardly makes one a "shitty" coder. It happens to the best of us out here in the real world. (I assume, by your outright disbelief at what I find to be common issues in C++ development, that you work with actual gods or something.)
Yeah, that was a silly typo.
Yes, RAII demands destructors, and stack unwinding demands destructors to be invoked, but you are in control of it: if your loop is time-critical, then you can get raw and avoid them.
How is it that a few percent of GC overhead spread over the whole app bother you so much while a few percent of exception-handling overhead spread over everything you haven't specifically sanitized is fine? Do you only work on exceptions-are-free-(except-a-bit-of-cold-memory)-until-you-throw platforms?
How have you used C++ to the point where you feel confident enough that none of what I'm saying could possibly be true to call me a liar and a plagiarist and yet completely ignore the reason that every decent C++ compiler has a switch to disable that entire language feature?
No compiler vendor has implemented a subset incompatibly. The only thing that is left is to clear up move semantics. Other than that, c++0x is ready. I am already using it in GCC 4.5, with exceptional results in code clarity.
The code clarity that GCC 4.5 affords you says little about what other vendors are doing. Still, you may be right. I'm still in pain from years of maintaining code that had to compile under MSVC, GCC, and a handful of the lesser compilers - each with their own unique and precious way of breaking your code.
Show me a case such as you describe.
I have on the other monitor a (sorry, closed-source) plugin to export polygonal models from Maya into a custom triangle mesh format. Mesh data is kept in simple STL vectors. We use basic algorithms methods like sort, binary search and copy.
In any build made with inlining disabled, a given test mesh (in this case 200,000 triangles) takes five minutes to export, as opposed to two and a half seconds in builds made with inlining on (so no, we're clearly not retards that can't pick the right algorithm for the task). I also have some pathologically bad models where the numbers are forty-two minutes to about fifteen seconds.
Careful profiling shows that the time is mostly lost in operators on various iterators (the sort that optimize away with inlining), followed by dispatches through multiple levels of overload discriminated by traits type that are used to optimize std::algorithm implementations (turning some copies into a memcpy instead of a *dst++=*src++ loop), followed by our vector math operators.
Yes, we could drop down to raw pointers and hand-inline everything in the hot loops, but in a project like that everything is in a hot loop, so what's the point of using C++ over plain C (besides Maya's plugin framework requiring C++)?
Bullshit. You are just quoting something you read over the internet. Show us a such a case.
[snip]
Again, big bullshit. Stop quoting random people that you read online.
That's funny, I don't see any quote tags in what you were responding to.
Could it possibly be that I have a brain and that these are my opinions based on my experiences? That the opinions resembling those you've read elsewhere were reached independently or are held because the other's words are well-enough validated by my own experience that I legitimately hold them as my own? Could it be that none of that occurred to you, or is it the case that you mindlessly assume anyone that differs in opinion from you is just dumb (which I understand, as such is common on Slashdot)?
Neither the cost is big, nor it is difficult to enforce rules.
It takes far longer to properly review a piece of C++ code which uses C++'s features to any significant extent than it does a piece of C# code of equivalent task complexity. It may not be "difficult" to keep up on code reviews and enforce rules, but difficulty has little to do with time spent.
I am not saying that c++ doesn't have its problems. It has, and a big list of them.
No, you're just saying that I must be stupid, a shitty programmer (or that my colleagues are such), lying, and mindlessly copy-pasting other people's (stupid, in your view) comments because the ways in which C++ has wasted my time differ from the ways it's wasted yours.