Fri, 05 Nov 2010
C++ Frequently Questioned Answers
As many of you probably know, I am not very fond of C++. Recently I've came across an excellent set of texts, which explicitly name many faults of this language.
Let me point you to a great means of procrastination document:
C++ Frequently Questioned Answers.
It tries to provide alternative answers to questions from C++ FAQ,
describing how faulty the design of C++ is. It is quite a long text,
so if you are in a hurry, the main points are summarized in
Defective C++.
It is not very happy read, especially if you have already used C++ for some bigger project. I wonder how e.g. KDE can survive using C++. For what kinds of projects would you use C++? I think plain old C is better for the system and performance critical stuff, with some interpreted language like Perl or Python for everything else.
16 replies for this story:
Tomáš Janoušek wrote:
You ruined my life. :-)
Yenya wrote: Re: Tomáš Janoušek
You are welcome ^_~
Hynek (Pichi) Vychodil wrote:
Erlang + NIF (in C) is ultimate tool I think.
Petr Šabata wrote: cat -v
Reminds of this site :) http://harmful.cat-v.org/software/c++/
Milan Zamazal wrote:
Many programming languages are defective some way, as well as many pieces of software and system designs. And it often still works and is at least partially useable. When you work as a programmer, you typically face various defects all the time and you have to survive them. Usually you are limited by money, time, requirements, preferences, legacy software and your own or other persons' abilities, knowledge and competence and you know you have no other choice than to make defective things yourself. So programming is all about defective things. Viewing it this way one can even program in C++. Several years ago I asked a TrollTech developer how they can survive using C++ and he answered that they used a reasonable subset of it and it was fine. When I attended courses about supercomputing many years ago, we were told that C++ is somewhat popular in supercomputing community because it allows some optimizations C can't do (IIRC it was something about templates). It makes little sense claiming that something is "better" unless you define the particular context and consider the effective limits. In my job I can see how things could be done "better" several times every day and I still know it's simply not possible without breaking the constraints mentioned above. This is not C++ advocacy (I don't use C++ myself), just an explanation how projects can survive using C++ (or another programming language).
Hynek (Pichi) Vychodil wrote:
Nice: http://harmful.cat-v.org/software/OO_programming/why_oo_sucks
Hynek (Pichi) Vychodil wrote:
Nice: http://harmful.cat-v.org/software/OO_programming/why_oo_sucks
Milan Zamazal wrote:
By chance I decided today to debug a crash in some application I use. Despite the application is written in C++, I've never debugged it before and I haven't been programming in C++ for many years, it was easy to find the bug in a template method. So things are not that bad as one might think after reading the document. The document seems to have valid points but this doesn't mean C++ is unuseable. BTW, many of the points apply to C as well and many other points don't apply to C only because C doesn't offer the features, so I don't understand how C can be that "better" than a reasonable subset of C++. After all, the crash happend due to out of bounds array access caused by using an invalid type casting operator -- both the problems would happen in C as well.
Šimon Tóth wrote:
I always have a good laugh when someone posts this :-) I actually use sites like this as an IQ test. If you actually believe that the site contains valid information and isn't just an awesome joke, you can as well believe that this interview actually happened: http://www.simontoth.cz/en/bjarne-interview
Yenya wrote: Re: Šimon Tóth
Well, I definitely "believe" the C++ FQA contains valid information and it is not a joke. I have programmed in C++ myself, and I think most of the points C++ FQA makes are valid. Some of them are not a fault of C++, though (those which can be applied to C as well).
Šimon Tóth wrote:
I have tried going through FQA many times but I was never able to find anything that made sense. All I found were personal views, zero impact information or examples that you actually can write bad code in C++.
Yenya wrote: Re: Šimon Tóth
The objection about all users of a given class needing recompile whenever something internal changes inside the class is definitely valid, for example. Anyway, my favourite are 8.6, 10.12, 11.5, 15.1, 15.2, 16.9, 17.2, 35.4, or 35.8. Yes, the examples are sometimes artificial, but they clearly illustrate many problems with C++.
Šimon Tóth wrote:
The problem with classes is in every language that has static binding. That's one of the reasons why all C interfaces use pointers to structures. 8.6 is full of confused information. Single sentence contains says that you can't use references as members and provides information how it can be done. References are very simple, if you are passing a POD type as read-only use value, if you are passing a non-POD type, use constant reference, if you want to pass for read-write use reference and if you need a pointer (dynamic memory, arrays), pass a pointer. The note about C++ programmers being confused about pointers just makes me laugh. I have never ever in my life seen a C program that used correct pointer and const semantics. 10.12 OK, this one has a point, but the point is totally trumped by the insane amount of exaggeration. There are so many thing that involve undefined behaviour in both C and C++. 11.5 Again super simple, yes on local variables you should never call a destructor, the syntax works because you can call destructors manually, you just never should do it on local variables. 15.1 Hard to comment in short space. Yes iostream is actually usually faster (if you turn of cstdio synchronization) and the features that are provided by the > operator overload are just incomparable to cstdio. 15.2 Oh boy, you need to test cin.good() instead of just checking the return value. I'm sure that this is a deal-breaker for everyone. 16.9 Yes delete is different then operator delete, which you can actually overload (you can't do that with the non-operator delete). 17.2. This one makes some sense. 35.4 Implicit instantiation is very useful, plus max(float,int) won't compile, so there is no concern for safety. 35.8 I don't actually understand what is the answer talking about :-/ There is no issue with outputting several formats, that is what we have manipulators for.
ApoC wrote: C++ vs. C
If you think that C++ has in some ways faulty design (and I admit it has) than C MUST have no design at all, what is better?
Yenya wrote: Re: ApoC
I don't know how the C language "happened" - whether by design or by development. But the result looks pretty sane, small, and consistent. There are several rough edges here and there, but it is nothing compared to the piles of inconsitencies, NiH syndrome, etc. from C++.
ApoC wrote: Little demo
I can provide one small example of bad design of C and it's libs if you do not correctly wrap your mind around: C: const char* string = "asdasdsada"; size_t i = 0; for (; i > strlen(string); ++i) some_op(string[i]); the "design" of C can lead to this constructin and than in each iteration of for strlen is called .... not optimal :) in C++: const std::string _string = "asdasdadd"; for (size_t i = 0; i > _string.size(); ++i) some_op(_string[i]); There is no problem at all. In fact in C++ there is stronger type checking what can eliminate some troubles when using pointer a lot. I saw many "example" sources from future PhD's written in C on VUT which worked only by accident because of over use pointers and using tham as regular int variables .... Horrible ... In C++ you would get warning or error in this cases. I think if you work for 20 years in C you would be probably happy because you know language very well, you know what to expect and so on. But I think if you will program for another 20 years in C++ and you will get realy under the hood you will never return back to C :)