Back to General and Gameplay Programming

Criticism of C++

Will Cassella · 2016-01-17T20:43:53

I've seen people criticize the C++ language in many different ways, and while much of that is legitimate, sometimes I feel they're missing the point. Probably the biggest compiled collection of criticisms would be the C++ FQA, which is a great example of what I'm talking about. Some of the earlier points about header files and undecidable syntax are agreeable awful, but some of the other points don't make a whole lot of sense. Defects 7, 8 and 9 are especially questionable, but I'm not going in to those. I just want to take a chance to rebute some claims against it I've seen online and in person. It has duplicate funcionality The most popular example I've seen of this is pointers and references, which I strongly disagree with. This is like saying that 'int' and 'float' are duplicates, since they both store numbers. While pointers and references can be seen as a means of "referencing" something, the way they work and are used (and the concepts they represent) are fundamentally different. Namely, a pointer is a value in itself, while a reference is not. I think "alias" would have been a better name, which may have reduced some of the confusion. It's also worth pointing out that references may not be null (the only way for that to happen would be to dereference a null pointer, which is undefined behavior), but in practice I have seen that occur (though not without having made poor mistakes). One thing I really like about references is they are the only thing I've seen in any language that actually indicate how "array[3] = 2" might work. It's unsafe This one I can empathize with, since it is much easier to write fundamentally broken code in C++ than in most other languages. However, the example of this I've seen people bring up is almost always pointer arithmetic, which is strange since that almost never occurs in real code (the only common case would be when its wrapped up in an iterator), and there's much easier and subtler ways to write broken code anyway. I guess this is just another example of people criticizing something without actually having much familiarity with it. In practice C++ can be very safe if written correctly, though I do wish it was just a bit safer, since I already have enough trouble sleeping at night. The syntax is ugly There are some cases where C++ can be a bit ugly (array declarations are weird, semicolons after classes are funky) but it's really just a matter of aesthetics. I think APL is pretty fuckin' ugly, but that's mainly because I don't understand it. C++ is in some cases much more verbose than other languages, but that's usually by necessity rather than design. Lambdas for example simply can't be as clean and pretty as those in C# because it would require the compiler to automatically decide whether you want to capture by value or reference, which would be unsafe (though it would be cool for zero-capture lambdas to be that pretty). C++11 has done a lot to make the language much more concise in some areas, and concepts are only going to make it better. In conclusion I'll probably think of more and edit this post when I do. There are a lot of things C++ could do better, and I feel like much of it goes back to having been built directly on top of C. However, there are a lot of things I think C++ has done well that I miss when working in other languages, and it bothers me when people unjustly criticize it.

General and Gameplay Programming Programming

Started by wcassella January 02, 2016 09:44 PM

143 comments, last by Ryan_001 8 years, 3 months ago

Bregma

9,461

January 08, 2016 09:14 PM

think 'C++' has many flaws. One of them is the functions.

Well, it's an interesting criticism, but I think it's a little off base for this topic.

The most fundamental construct of the C programming language is its use of functions parameterized on pass-by-value arguments. Using pass-by-value instead of some of the more complex methods used by competing languages at the time (pass-by-descriptor in FORTRAN, pass-by-reference in Algol, functional programming in LISP) allowed a C language compiler to be very small, very fast, and very portable and made most of the programs written in it smaller, faster, and more portable too. Hence its long-term continuing success over its rivals over the past 40-odd years.

The rather verbose post above criticizes the pass-by-value machanism in favour of a pass-by-name architecture. Fair enough: there are a number of ways of passing parameters into subroutines, and the designers of the languages are usually aware of the tradeoffs involved when choose which mechanism(s) to specify. Perhaps in alternate universes we all use Modula-3 to write complex systems (except for MacOS, which uses Oberon). Fact is, pass-by-value is Good Enough and easier to get right when writing a compiler, even if sometimes it can cause performace problems when not used correctly.

Stephen M. Webb
Professional Free Software Developer

vinSQL

101

January 08, 2016 10:57 PM

think 'C++' has many flaws. One of them is the functions.

Well, it's an interesting criticism, but I think it's a little off base for this topic.

The most fundamental construct of the C programming language is its use of functions parameterized on pass-by-value arguments. Using pass-by-value instead of some of the more complex methods used by competing languages at the time (pass-by-descriptor in FORTRAN, pass-by-reference in Algol, functional programming in LISP) allowed a C language compiler to be very small, very fast, and very portable and made most of the programs written in it smaller, faster, and more portable too. Hence its long-term continuing success over its rivals over the past 40-odd years.

The rather verbose post above criticizes the pass-by-value machanism in favour of a pass-by-name architecture. Fair enough: there are a number of ways of passing parameters into subroutines, and the designers of the languages are usually aware of the tradeoffs involved when choose which mechanism(s) to specify. Perhaps in alternate universes we all use Modula-3 to write complex systems (except for MacOS, which uses Oberon). Fact is, pass-by-value is Good Enough and easier to get right when writing a compiler, even if sometimes it can cause performace problems when not used correctly.

Here is not about that - in every case it's the same. I mean the function called expects the calle to store some variables on the stack which locations are well-known (just like any normal variables). I'm not proposing to change pass-by-value mechanism. Instead what I am proposing is the ability to modify function arguments and return value the same way as any normal variable. Not in the limited way we can only do now - by simply copy-initalizing. This will eventually allow the creation of faster, optimized code on some old compilers and also will give the programmer a better idea of what he is actually doing. Although 'C' (and so 'C++' partially) have some bigger issues to deal with.

Bregma

9,461

January 09, 2016 01:04 AM

I'm not proposing to change pass-by-value mechanism. Instead what I am proposing is the ability to modify function arguments and return value the same way as any normal variable.

You just gave the definition of pass-by-name. You're proposing to use pass-by-name instead of pass-by-value.

Algol used pass-by-name.

Turns out it can be really hard to write good code using pass-by-name. Consider this classic snippet of Algol code.

 begin integer i;
        integer procedure sum(i, j);
            integer i, j;
                comment parameters passed by name;
            begin integer sm; sm := 0;
                for i := 1 step 1 until 100 do sm := sm + j;
                sum := sm
            end;
        print(sum(i, i*10 ))

Because the parameter "j" is "i+10" every time i gets incremented, so does j.

Stephen M. Webb
Professional Free Software Developer

Alessio1989

4,648

January 09, 2016 01:21 AM

Pass by value is the meaning of life.

"Recursion is the first step towards madness." - "Skegg?ld, Skálm?ld, Skildir ro Klofnir!"
Direct3D 12 quick reference: https://github.com/alessiot89/D3D12QuickRef/

wcassella

843

Author

January 09, 2016 05:14 AM

Just a bit off topic, but I'd like to make a criticism of the Jonathon Blow video that was posted a few pages back.

What I like

I like his point about exceptions. Despite their popularity in many programming languages, the way they work is fairly non-intuitive, and I think Go made the right decision with allowing functions to return multiple values as the primary means of error reporting; it makes error handling clean, while at the same time hard to ignore. However, I believe there's still a case for having "loud" errors than may be recovered from at some level, even if that "recovery" is just to halt with an error message generated from one point in the code base.

I also agree that being able to do low-level manipulations with a high degree of confidence is a very good thing, and that programmer morale is an important aspect of any code base.

I get what he's saying in how memory isn't quite a "resource" in the same sense as a the others listed (mutexes, texture maps, etc), however, I don't really see why it matters. Cleaning things up is still cleaning things up.

What I don't like

The biggest point in this video seems to be about how RAII is bad, but the only real point he's made against it is how it's "boring". The rubber has to hit the road somewhere as far as resource cleanup is concerned, and I'd rather it be done in a special cleanup method than anywhere else. Having that method called automatically is really nice, which is why you should make that method the destructor (hence, RAII). He also claims that RAII exists because of exceptions, but that's kind of a moot point seeing as many C++ programmers heavily make use of RAII while avoiding exceptions completely.

One rather bizarre portion of the video is how at one point he criticizes the syntax for std::unique_ptr, when he's actually using it incorrectly. It's pretty inconsequential for the purpose of the video, but a mistake as simple as that really draws into question how much experience he has with these C++ abstractions, and subsequently whether he has enough to properly criticize them (at least in my mind). However, I do agree that it would be nice if these smart pointers and ownership semantics were more strongly integrated into the language, though maybe not with the semantics he's suggesting.

Anyway, I've seen plenty of smart people give bad advice (I've certainly given my fair share of it, and I can't even claim to be that smart). He's given plenty of good advice elsewhere even in the same video, but I think you should take everything people tell you with at least a little bit of salt. It'll be interesting to see what happens with this language he's developing, though I'm not convinced it'll be the game industry replacement for C++ he seems to be aiming for.

Criticism of C++

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Criticism of C++

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines