What is wrong with C++ FQA?

[EzwRko23]

I have heard that some of you find the C++ FQA reasoning flawed. But I have never heard of anyone saying what exactly is wrong with it (except that sometimes its form is too emotional).

Here is a link (if someone does not know it): http://yosefk.com/c++fqa/

[Seraphimsan]

Theres nothing wrong with it, some of it is opinion from what I remember (could be wrong) but that's not a big deal. C++ is flawed, that's no secret. But even so, you'd be hard pressed to HONESTLY give us an example of a language that is perfect.

[Bazzy]

Here are some random picks that I find quite retarded

[15.12] How can I open a stream in binary mode?

FAQ: Open the stream with the std::ios::binary flag. That way, the stream will not translate between '\n' and the target platform representation of line termination, which may be different (for instance, Windows uses CRLF).

FQA: With fopen, pass the "b" character in the options string. This whole issue is pretty annoying, especially if you work with binary files on a system where '\n' is not actually translated, and forget to open them as binary, and everything works, and then you port the program to a system where '\n' actually is translated, and then you have to find all those cases and open the files as binary. However, this is not the fault of C++. It is the fault of the distributed nature of the human race, which fails to standardize the simplest things.

Many programs may screw up your binary files due to this family of issues, for instance, many FTP clients will do so unless explicitly told otherwise.

[11.4] Can I overload the destructor for my class?

FAQ: No. Destructors never have parameters or return values. And you're not supposed to call destructors explicitly, so you couldn't use parameters or return values anyway.

FQA: Why do you want to overload destructors? Do you like C++ overloading? Are you sure? But the lack of return values is a pity - no way to handle errors. Let's hope they won't happen, shall we?

[33.9] I need something like function-pointers, but with more flexibility and/or thread-safety; is there another way?

FAQ: A functionoid is what you need.

FQA: "Functionoid" rhymes with "marketroid", and is a term local to the FAQ, used instead of the standard term "functor".

[EzwRko23]

What is exactly wrong with that?

FQA: Why do you want to overload destructors? Do you like C++ overloading? Are you sure? But the lack of return values is a pity - no way to handle errors. Let's hope they won't happen, shall we?

The inability to signal errors from destructors is annoying (and again: not orthogonal with the rest of the language). That is why iostream uses status flags for error handling and not exceptions.

[Bazzy]

How is that related to destructor overloading?

[EzwRko23]

It is related to the answer from FAQ: "Destructors never have parameters or return values"

[Bazzy]

Let's say that destructors did have return values

class MyClass
{
    int ~MyClass();
};

void f()
{
    MyClass obj;

    int how_am_I_supposed_to_get_a_value_from_obj_destructor_without_calling_it_explicitly,
        so_at_that_point_it_could_have_been_just_a_normal_method; 
    // and how could I pass arguments to it?
}

[EzwRko23]

Noone claims they should return values. But the fact they don't return values and they don't support exceptions means that you cannot handle errors.

[Seraphimsan]

I handle errors in destructors all the time.

class myClass{
	public:
		float* pFloats;
		~myClass();
		myClass(int sizeOfpFloats);
};

myClass::myClass(int sizeOfpFloats){
	pFloats = new float[sizeOfpFloats];
	return;
}

myClass::~myClass(){
	delete[] pFloats;
	if(/*some random error*/ true) //just cause I couldnt think of an error that would 
                                   //ALWAYS occur lets set it to always be true for the sake of reason
		standardEH.errorCode = 1;
	else
		standardEH.errorCode = 0;
	return;
}

struct errorHandler{
	int errorCode;
	void codeParser();
}standardEH;

void errorHandler::codeParser(){
	switch(errorCode){
		case 0:
			return;
		case 1:
			cout << "some random error occured";
			break;
		default:
			return;
	}
	return;
}

int main(void){
	myClass* mcObj = new myClass(10);
	delete myClass;
	standardEH.codeParser();
}

edit: syntax error in my code :P

[Disch]

Here's one:

[6.2] Is C++ a perfect language?

FAQ: No, and it shouldn't be, it should be practical, which, as we've just seen, it is. Perfect is for academy, practical is for business.

FQA: No language is "perfect" because our requirements from a "perfect" language are inconsistent with each other. So instead of perfection, good languages provide consistency and usability. This can be called "practical" from the point of view of language users.

C++ is different - it's designed for perfection.

It actually isn't designed for perfection, as the FAQ he just quoted stated, and as numerous documents and articles written by the developers have stated.

Where other languages give you a feature, C++ gives you meta-features. Instead of built-in strings and vectors, it gives you templates. Instead of garbage collection, it gives you smart pointers.

This is because C++ is a lower level language than those that offer built-in strings, vectors, and garbage collection. It has nothing to do with striving for perfection.

This is actually the focal point for most of his arguments. He simply fails to (or refuses to) acknowledge that C++ is a lower level language than the languages he likes to compare it to, and thus doesn't serve the same purpose.

std::string, std::vector, etc are offered for conveninence.

Why change the language to add these types as built-in types when you can just write the code for them? Making them bulit-in types would do nothing but make the language and compilers even more complicated than they already are.

Of course if string and vector were built in types, he would complain that there's no benefit in them being built in types, and all it does is make the language more complicated.



I could go on, but I'm at work and can only post during downtime.

[Duthomhas]

Mr. Kreinin is more interested in spewing C++ hate than he is with more worthwhile expenditures of his time. Most of the "FQA" is hyperbole and propaganda. He often twists facts to make his point. And it is clear that his biases regularly override any objective, professional programming experience (which I'm not so sure he has). Many of his claims are simply absurd. If he could just focus himself a little he might make some reasonable arguments, but as it is he spews too many side references to be taken seriously (a common tactic of those who wish to appear more knowledgeable than they are).
http://xkcd.com/132/

[EzwRko23]

@Seraphimsan: your method uses a global variable and doesn't work in multithreaded environment.
And besides, how do you handle two destructions in a row? One will overwrite the result of another one. It is easy to forget to handle error.

It actually isn't designed for perfection, as the FAQ he just quoted stated, and as numerous documents and articles written by the developers have stated.

For me C++ is neither perfect nor practical. Practical is Perl. For language to be practical it must give a reasonably fast and easy ways of solving **typical** programming problems. Anyway, it is a matter of opinion and application.

This is actually the focal point for most of his arguments. He simply fails to (or refuses to) acknowledge that C++ is a lower level language than the languages he likes to compare it to, and thus doesn't serve the same purpose.

I think he would not do this if C++ weren't marketed as a HLL by many. From the Kreinin's blogs you can see, he is a low-level programmer; if we can trust him, he did a lot of bare-metal programming.

Of course if string and vector were built in types, he would complain that there's no benefit in them being built in types, and all it does is make the language more complicated.

I disagree with the FQA here. I think the real problem is that templates, which are used to implement these features, are not enough practical to make strings/vectors easy to use. While templates provide quite an amusing amount of flexibility and fun for academics (all those crazy statements about Turing completeness), they fail miserably at some quite important areas like sensible error messages, fast compile times or IDE support. .NET/Java/Scala generics approach is much more practical (and Scala's type system is Turing complete, btw).

And it is clear that his biases regularly override any objective, professional programming experience

I have over 5 years of commercial C++ programming and I agree with most of the FQA claims
Sometimes he exaggerates, but, anyway, you don't have a <X>-FQA for any other language.
Try to do one, for e.g. Java or Scala. You will probably run out of ideas after 5 or 10 points.

[Seraphimsan]

This was just a VERY simplistic implementation of what I normally do. it's cumbersome, but still possible.

[Disch]

Try to do one, for e.g. Java or Scala. You will probably run out of ideas after 5 or 10 points.

The C++-FQA guy ran out of ideas after 3 points.

All of his responses are rephrases of the exact same complaints:

- C++ has new features to replace C approaches
- slow compile time
- templates have incomprehensible errors

If you remove those 3 points, you remove 99% of the FQA.

[Duthomhas]

I have over 5 years of commercial C++ programming and I agree with most of the FQA claims

So? I have over 23 years experience, but I don't use that as an excuse for my opinion. Give me some facts.

... but, anyway, you don't have a <X>-FQA for any other language.

Again: so? Things that are big, visible, iconic, oft used, etc always get the most crap. That does not constitute proof for the validity of anything. Oh, and your statement is an obvious logical fallacy: The existence, or lack thereof, of FQAs for other languages validate neither the FQA nor its claims against C++.

I know a considerable number of languages, including Java. My personal opinion is that Java has some significant design flaws. However, that does not constitute any good reason to burn all computers that have been touched by it. Java is used in industry all the time, to good effect. I can easily use it effectively to accomplish given requirements. Were it not so, Java really would be worthless. My dislike for Java does not make it a bad language.


If you hate C++ so much, why do you stay here? Find something better to do with your life. Program in Java, or Scala. Or write yourself a better C++, or other language of your preference. Quit annoying us with your anti-C++ crap. This is, after all, a C++ forum. People here tend to like or, at the very least, tolerate C++ and we want to deal with it rather than spend time hating it.

[Disch]

Again: so? Things that are big, visible, iconic, oft used, etc always get the most crap.

Reminds me of that one quote..

and I'm paraphrasing because I don't remember it exactly:

"There are 2 kinds of programming langauges. Ones that everyone complains about, and ones that nobody uses."

[LB]

It sounds better if you replace "ones" with "those"

[Albatross]

Shouldn't we be ignoring trolls and flame-baiters rather than feeding them and/or eating their bait?

-Albatross

[NGen]

I like these arguments. I've learned a few things from them, although I'm sure that at this point the people who are arguing are probably tired of it.

[Seraphimsan]

and imperfect.