About

Accounts

You are at the newest post.Click here
to check if anything new just came in.

16:40

“

C++ has an astonishingly complicated grammar, which means that compilation takes forever and other tools don't work as well as they do for languages with simpler grammars, like C or Java.

C++ doesn't really have compile-time encapsulation: if you add a private member to a class, you need to recompile everything that uses that class even though the class's public interface didn't change. That woudn't be so bad in and of itself except that C++, again, takes forever to compile.

C++ also doesn't have run-time encapsulation or really any serious run-time error checking that you don't do yourself. Yes, it's for performance reasons, but some people are working on problems that aren't performance-critical and would prefer a language that doesn't pound nails through our dicks. (if it doesn't have encapsulation, why do they call it "object oriented?")

C++'s exception support is hilariously broken. 1) If you've allocated some memory for an object, and then you throw an exception, you don't have that pointer anymore, and because C++ doesn't have garbage collection you've just leaked memory. The only way around this is to implement garbage collection yourself; C++ weenies call this "RAII" and if they're really far down the rabbit hole they sometimes don't even realize that it's just them implementing shitty reference-counting garbage collection. 2) You can't throw exceptions in destructors. Well, you can, but when an exception is raised, all the destructor for objects on the stack are called, and if one of them throws an exception while you're already handling an exception the program terminates. Seriously, that's what the standard says, I'm not making this up. So you can't throw exceptions in destructors, or call any function that might throw an exception. 3) In every major compiler I've used, exception handling support is implemented in such a way that it slows down every function call you make. Yes, it's only slightly, but it means if you really care about performance, you can't use exceptions, and if you don't care about performance why the hell are you using C++? And even if you want to use them they're almost worthless; I mean you can't even get a goddamn stack trace out of them. You can throw arbitrary objects, but the catcher can't figure out what the hell the object is because of C++'s lack of reflection. Etc.

C++, in an effort to be sort-of compatible with C (except where it's not compatible with C, which makes you wonder why they bothered in the first place) keeps all of C's features while creating duplicate features with their own new, horrifying problems. So you have C++ templates, but you still need to deal with C macros. You have std::vectors, but you still need to deal with arrays. You have std::string and char*, and neither is particularly good. Making things even funnier, C++ doesn't like to use its new features and prefers the C stuff: a string literal is a char*, not a std::string, the arguments to main() are int argc, char** argv, rather than something sensible like std::vector args, iostream does not take std::string for its filename arguments, etc.

While we're on the subject, the standard iostream is pants-on-head retarded. The streams are stateful, which means that std::cout foo; depends not only on the values of cout, foo, and the overloaded left bit shift operator, but also on whatever's been sent to cout in the past. You send values like std::hex or std::setw(int) to set parameters, so when you grab a stream you don't really know what the fuck will happen. This is supposed to be an improvement over printf? They're verbose as hell, too: say you're printing some hex numbers. In C, you'd use "printf("0x%08xn", x);" for int x. In C++, you use "std::cout std::hex std::setfill('0') std::setw(8) x std::dec std::endl;" It's absurd.

The standard library is completely anemic. I'm not even talking about GUI stuff, here: there's no platform-independent way to do some really basic stuff like pausing for a length of time, or starting a new thread. You can use some "platform independent library wrapper" like ACE, but which of the many, many mutually incompatible wrappers are you going to use? Is that wrapper still going to be maintained when you're working on your program a few years down the line? Do you need to ship this wrapper's runtime to your customers? Why the hell doesn't the language spec specify some of this shit? The STL (and any other template-heavy code, particularly code that does a lot of operator overloading, too) also just loves to dump gigantic unintelligible multi-kilobyte error messages at the slightest provocation.

I could go on, really. If you've only used C++ in class or in personal projects then it seems like a neat language; it's not until you need to use it for a large codebase with lots of other people, some of whom have already moved on to other companies, that you realize what an unholy mess the language is.