Talk:Criticism of C++

Where did this page come from?

The history of this article is really odd. It seems like User:Rincewind82 was working on a personal user-land criticisms page, and then a completely different user decided to move it into this page. This seems rather dubious to me. User Rincewind82 has contributed to exactly two pages: this one and a few things with Lean software development. Whereas Anthony is a well-established user. But his contributions rarely stray into technology. I'm curious about what happened here. Did Rincewind82 ask Anthony to move this page, or did Anthony do that on his own? And if it's the latter, why? Korval (talk) 17:14, 26 January 2016 (UTC)

Hi, the article was written by me. I first made it in my sandbox not to disturb anyone. Later I was unable to move the article for some reason. Probably because of a redirect already being there. I then made a request to move the article on Requested_moves/Technical_requests. I hope this was ok? I'm new on Wikipedia and I'm not yet used to the procedures here. Rincewind82 (talk) 19:08, 26 January 2016 (UTC)

It's fine. The circumstances seemed a bit odd, which is why I asked. But your explanation makes sense. As a new user, you might not have the ability to make such a move, so you invoked a process to get it moved for you. That's fine. Korval (talk) 01:13, 28 January 2016 (UTC)

Lacking POSIX suppport in <iostream>

In the example code function POSIX_Poll, is there a reason why fdopen(fd.fd, "r") is used instead of just File? Also, mixed case variable names are discouraged by the kernel coding standard.Michael9422 (talk) 22:00, 24 May 2016 (UTC)

User:Michael9422 Hi Michael! No, there is no reason. I only wanted to show how to convert between descriptors and file structs. Feel free to change the example regarding this and the formatting. Rincewind82 (talk) 18:37, 25 May 2016 (UTC)

Type safety question

I saw this example given as a critique of the "C++ type-safety" claims. Can someone explain to me why this program compiles without errors or warnings, despite not using a cast?

class A { public: int a;};
class B : public A { public: int b;} barray[5];
A *aarray = barray;
int main()
{
        aarray[4].a = 5;
}

Michael9422 (talk) 04:39, 27 May 2016 (UTC)

This question is probably off-topic here on this talk page, and better suited for the computing reference desk. Anyway, in the line

A *aarray = barray;

the expression barray of type B[5] "decays" into a pointer to a B (namely the address of the array's first element), and C++ explicitly allows assignment from a pointer to the derived class B to a pointer to B's base class A. Now, in the line

aarray[4].a = 5;

the expression aarray[4] is syntactic sugar for *(aarray + 4) (pointer arithmetic). Evaluating this expression when aarray points to the first element of barray is undefined behavior because aarray does not point into an array of As. The compiler, however, is not required to detect this violation of the language rules (and in fact in general cannot detect violations of this language rule), trusting the author of that code that he know what he's doing. – Tea2min (talk) 12:42, 27 May 2016 (UTC)

Thanks. Michael9422 (talk) 13:26, 28 May 2016 (UTC)

I have a follow up question. In the C++ wikipedia article, under the section Philosopy, it says

* No implicit violations of the type system (but allow explicit violations; that is, those explicitly requested by the programmer).

Is the buggy assignment above an example of the programmer explicitly requesting a violation? (I notice that both GCC and clang produce warnings for incompatible structure pointer assignments without casts in C programs, but no warnings for (at least this particular) incompatible object (class) pointer assignment in C++.)Michael9422 (talk) 01:59, 9 June 2016 (UTC)

It's not the assignment that's buggy, it's the application of the subscription operator [] that's already undefined. And it's not an example of the programmer explicitly requesting a violation of the type system (as I understand that phrase), it's undefined behavior (as opposed to implementation-defined behavior or unspecified behavior). The compiler is explicitly allowed to assume that aarray in the expression *(aarray + 4) points to an element of a big enough array of As, no questions asked. The compiler is not required (and generally not able) to detect violations of this precondition of pointer arithmetic.

I take the phrase "explicitly requesting a violation of the type system" to mean something like a static_cast or a const_cast or, more explicity, a reinterpret_cast. The mapping performed by reinterpret_cast for example is implementation-defined, and the C++ standard explicitly lists the legal applications of reinterpret_cast. This includes for example converting a pointer to any integral type large enough to hold it and back. – Tea2min (talk) 07:26, 9 June 2016 (UTC)

I believe that I understand your explanation. However, if I write a similar program in C,

struct A { int a;};
struct B { struct A a; int b;} barray[5];
struct A *aarray = barray;
int main()
{
        aarray[4].a = 5;
}

then compilers will produce a warning about the incompatible assignment on line 3 (at least GCC and clang). That is what I would expect for the C++ version too. Since it does not, it seems to me as though this is an example of C++'s type system being weaker than C's. (In both code examples, I really should have put the *aarray = barray in the main function instead, but that won't change any results.) Michael9422 (talk) 15:20, 9 June 2016 (UTC)

Actually, that's an example for C++'s type system being stronger than C's! A conforming C++ compiler is required to report an error on line 3 in the second code example: as in the first example, on assignment to a variable of pointer type the array barray decays to a pointer to the first element of that array, that is, to a pointer to an instance of struct B, and the language rules forbid assigning such a pointer to a pointer to an A. Instances of derived classes are related in the sense that every instance of class B in the first code example above is-a A, and that's the reason the language rules allow the assignment of a pointer to a B to a pointer to an A. This relation does not hold for instances of struct B and instances of struct A in the second code example. An instance of struct B contains an instance of struct A but it is not true that an instance of struct B is-a instance of struct A. – Tea2min (talk) 17:48, 9 June 2016 (UTC)

I disagree. The difference between the compiler producing an error or a warning in this case is not significant. What is significant is that the idiomatic way of doing it (making roughly the same mistake) in C++ produces no error or warning. Anyway, I do not intend to include this example in the article. Thanks for your help. Michael9422 (talk) 18:41, 9 June 2016 (UTC)

Then we will have to agree to disagree. And I must protest: the first example is completely unidiomatic C++, precisely because of the well-known dangers inherent in pointer arithmetic. But this is not the place for that discussion. – Tea2min (talk) 19:09, 9 June 2016 (UTC)

I acknowledge that the terminology I used, "idiomatic", is incorrect. My mistake. I just meant using "class" instead of "struct". Michael9422 (talk) 20:04, 9 June 2016 (UTC)

Complexity

I think that the article could use a section called 'complexity'. A frequent criticism is that the language is too complicated (from, for example, programmers Ken Thompson and Eric Raymond; or Thomas Becker's blog article "C++ and the culture of complexity"). That results in more time and effort for developers to become proficient compared to simpler languages, and is exacerbated by the many unexpected language pitfalls, or hidden "gotchas". The complexity also makes it harder to read and understand code written by others, which can, for example, reduce productivity for software projects with many contributors. Also, the higher level, abstract features that C++ adds to C, tend to break the tight correspondence C has to machine code (Linus Torvalds says it "[breaks] the mental model", or something to that effect), making those features undesirable and probably counterproductive for systems level programming (this is also expressed by Martin Sustrik regarding ZeroMQ).Michael9422 (talk) 19:25, 8 June 2016 (UTC)

What do other editors think? Michael9422 (talk) 20:14, 8 June 2016 (UTC)

There are other people too who have said that the complexity of the language is a problem. Besides Ken Thompson, several of the programmers interviewed in the book "Coders at Work" make that claim (their quotes are in the link to excerpts from the book in the External Links section). Bjarne Stroustrup has said "Within C++ there is a much smaller and cleaner language struggling to get out" and "I’m convinced that you could design a language about a tenth of the size of C++ (whichever way you measure size) providing roughly what C++ does..." Michael9422 (talk) 16:24, 1 September 2016 (UTC)

I will also point out that most, if not all, of the foreign language wikipedia articles about C++ that have a criticism section include a mention of excessive complexity, at least judging by google's translation. Michael9422 (talk) 18:17, 22 June 2017 (UTC)

I think the problem with a section on complexity, is that it's a pretty difficult thing to quantify in objective terms that are suitable for Wikipedia. A good starting point may be feature orthogonality. Eg. how constructors may only fail via exceptions (and the flexibility implications of this, the ZeroMQ author talked about this), how the semantics of C++03 complicated the design of move semantics, how template specializations interacted with the design of concepts etc. There seems to be a trend here: overly eager adoption of potentially flawed designs. 79.114.11.51 (talk) 08:50, 23 June 2019 (UTC)

A problem solving and programming principle is to use a simple language, as few things as you can, that is called the Ockham Razzor, C has just the essential things, it has about 30 keywords and a well written book by Brian Kernighan about 300pp if my memory do not betrays me. C++ has about 300 keywords and an about 1600pp reference book. Who can master it? not even as his author claims that it is OK to use a subset. No no no, everything should fit fine together with that baroque design, it is impossible to be sure that one has a consistent use of the language because there is an exponential growth of interaction to take into account, Stroustroup is very far from the Small is Beautiful philosophy in vogue in ATT Bell Labs when Unix, C, groff, awk, sed, pic, etc. where created, Stroustroup did not learn to write simple systems, he just published his ill designed language naming it C++ to say that it is a better C, but it is not. In one of his writings where he explains what is OO vs data abstraction one can see many misconceptions which are reflected in his language and descendants of it. — Preceding unsigned comment added by 2806:106E:B:2E34:84BD:FC42:A6BB:76D5 (talk) 20:02, 19 September 2022 (UTC)

External Links

I recently added some external links to this article (too many actually) that were subsequently removed by other editors. I do not intend to restore them, but I want to point out that there are quite a few other articles, about software at least, that have external links to blogs or humorous articles that do not meet the same wikipedia guidelines given as the reason for removing the links that I added. For example, see the wikipedia article 'Programming productivity'. Should those links be removed? Michael9422 (talk) 16:12, 12 June 2016 (UTC)

Strings without Unicode

There's no point in the criticism that std::string does not support unicode, being a sequence of bytes. Thus, it's basically encoding agnostic.

Furthermore, the point about length() is of no value: Requiring the function to return the number of code points is nothing more than a special case (why not "grapheme clusters" or "user perceived characters"?), and does not make any sense with unspecified encoding. In fact (and talking about Unicode and a specific encoding), when interfacing with other software components, the length in bytes is what's needed often enough.

See [1] for further arguments on the topic.

As a result, I'd like to have the "Strings without Unicode" section deleted. Alternatively, I'd suggest to add the arguments above to adhere to the "Neutral point of view" principle.

mkluwe (talk) 19:44, 22 November 2016 (UTC)

the way it's worded, the criticism is perhaps poorly worded and unsourced. It could be written to reflect the issues highlighted by n3336 (which has now morphed into p0353r1) --Cubbi (talk) 03:58, 23 November 2016 (UTC)

Agree with Mkluwe - the arguer does not understand text encoding and has conflated "byte", "codepoint" and "character". The assertiveness of the argument, despite its clueless premise, annoyed me so much that I renamed the section and rewrote the example to show the real problem: a source-file's encoding determines the bytes in a string-literal, even when you think it shouldn't.--KrisW1001 — Preceding unsigned comment added by KrisW1001 (talk • contribs) 11:15, 29 April 2019 (UTC)

Undefined behavior and another notables missing from the list

How is it that a laundry list of complaints and criticism of C++ was assembled reaching several pages, but no one wrote anything about undefined behavior? Or the "strict aliasing rule" and the difficulty of diagnosing such problems in real code bases? Or the "static initialization fiasco"? Or the lack of a common ABI and the difficulties of distributing C++ programs to multiple platforms, and the plethora of different packaging systems for each operating system for obtaining the dependencies? Speaking as someone who uses C++ regularly, many of the most severe difficulties of using C++ are not mentioned, and many of the things given a lot of space in the article are comparatively trivial in practice.

IMO the article needs attention from an expert. Many of the categories are not actually criticism of the C++ language, but rather of the C++ standard library -- global format state of iostream, heap allocations in containers, iterators...

I like C++, but there's no doubt that there's a lot of crap in the foundations, which threatens the security and performance of real systems in the wild, and creates a lot of problems and headaches for software engineers. That kind of discussion is probably worthy of wikipedia. A lot of the stuff that is mentioned in this article comes off as "pet peeves" rather than serious criticism.

96.81.51.113 (talk) 22:52, 7 February 2017 (UTC)

None of the stuff you listed are negatives of C++ the language, but rather consequences of C++ being learned and taught improperly, because there are huge traditions of using C and C++ incorrectly and nonstandardly.

To teach good programming practice, the theoretical foundations must be boarded first, then one understand the structure of the language to know how to implement an abstractly defined program to translate it to a programming language preserving the semantics. That is not ease to o with C++, because it is not well designed, the C++ author misunderstands the theory, see for example how he implemented "lambdas" in C++, since the beginning he misunderstood what an abstract data type is. He used structures to implement overloading, that is OK because an abstract data type is essentially an algebraic system whose operations should be specified abstractly with axioms, the implementation should hide the details from the user, who should just understand the abstract specification and use the implementation in a very straight way, with the confusing use of classes as structures which goes beyond the notion of algebra as a mathematical structure adding more than what was needed introducing an anthropomorphic notion of objects sending messages to order what to do to other objects and an unnecessary over-encapsulation. That is the original C++ design sin. With that I hope that it is clear that is not ease to teach those concepts with a language that implement them in a wrong and confusing way. Simula 67 had another design in mind, the authors generalized what is needed to do simulations of the kind used to study queues. They built a good language for that domain, which resulted interesting for general computing because the notion of concurrency was implicit on it and concurrency is an essential feature in computing. — Preceding unsigned comment added by 2806:106E:B:2E34:84BD:FC42:A6BB:76D5 (talk) 20:45, 19 September 2022 (UTC)

On the other hand, part of that stuff (the UB problems) were "caused" by the standards committees failing to standardize the already existing language (C, C++ was only standardized a decade later) and instead restricting the semantics of the language as compared with the implementations and code traditions that existed before the standard. I am not reckoning about whether the committees were wrong to do this, but it is certainly a big part of the pervasive incorrect use of C and C++, which still persists.

BTW, this is coming from someone who does not like C++. 213.149.61.212 (talk) 22:56, 9 November 2017 (UTC)

The thing is that both C and C++ were created as "living languages" which were readily accepted and saw widespread use before there even was any committee (as opposed to "lab bred" languages, or languages that were otherwise "in the hands" of a single entity). The first C from 1972 to C89, the first C++ ("C with classes") from 1983 to C++98... had the committees been stricter about their rulings, they would have invalidated huge code bases, alienated major contributors, and / or risked fracturing the language into lots of mutually-incompatible dialects. -- DevSolar2 (talk) 14:53, 13 November 2017 (UTC)

I agree with the original point. The article hits some very specific criticisms, but is missing big picture things like UB and Complexity. Maybe a small step would be to rework the Iterator section as a UB section. The problems it lists with Iterators seem to be more UB. Quimn (talk) 00:01, 3 May 2020 (UTC)

Code bloat citation removal

This source

<ref>{{Cite web|url=http://gameangst.com/?p=226|title=Minimizing Code Bloat: Template Overspecialization|author=Adrian Stone}}</ref>

that I had added previously was removed recently from the section named 'code bloat', but I think it is appropriate. What do other editors think? Michael9422 (talk) 19:25, 13 March 2017 (UTC)

"Heap allocation in containers" obsolete?

I feel the whole section is obsolete since std::array...?!? -- DevSolar2 (talk) 11:54, 26 October 2017 (UTC)

I agree, removed. Quimn (talk) 01:59, 2 May 2020 (UTC)

Grammar

C++'s awfully complicated grammar should be discussed, and how that makes parsing it slow. 213.149.61.212 (talk) 20:17, 9 November 2017 (UTC)

That is being done in the very first paragraph of the article...? -- DevSolar2 (talk) 14:54, 13 November 2017 (UTC)

Back then, I don't know, but today in 2024, there isn’t anything in this article about the complexity of C++ syntax, which to my knowledge is a major source of criticism (most vexing parse, ambiguities with < and >, parsing being undecidable and who knows what else). Maëlan 15:14, 4 May 2024 (UTC)

What's the significance of the quote in the lead?

In the lead, a quote by the creator of C++ reads as so:

"There are only two kinds of languages: the ones people complain about and the ones nobody uses."

Let me quote, I believe Erik Meijer said it, "there are two kind of programming languages, invented and discovered ... discovered languages are the product of research while invented languages are just based in someone inspiration", it was said telling how many researchers developed many convergent languages and decided to unify they effort developing Haskell, a discovered language. C is not really an invented language it emerged from the need to have a systems programming language to provide a portable and abstract view of the random access machine with the goal to be small, just with elementary features, it is extensible through library functions like printf in stdio.h, which in other languages was part of the language. C is not a high level language, although it looks like one, because it is well designed for its original goal. With C++, one could expect to have the features present in high level languages, in particular facilities to define abstract data types. but it was done in a wrong way introducing unnecessary features far from being a small and simple more close to the notion that motivated it, in part due to a misunderstanding of the concepts and as later became apparent, the tendency of Stroustrup to add more and more features that occurs to him. It is an invented language with many flaws. Stroustrup has been reluctant to compare C++ with other languages is quite closed to criticism. But programming languages are not music, it is not a matter o taste, to judge them, there are mathematical foundations of computing to take into account to design, reliable, safe, expressive programming languages, that is crucial to build programs to control medical life support devices, airplanes, cars, and many more applications whose failure cause deaths. Of course, it is very important in other areas like manufacturing, management and financial systems. — Preceding unsigned comment added by 187.168.111.50 (talk) 21:26, 19 September 2022 (UTC)

What's the significance of it? What's the point? It doesn't seem notable nor relevant enough to warrant its position. It rather looks like someone inserted it to display Bjarne Stroustrup as dismissive with criticism of C++. KlayLay (talk) 01:50, 8 August 2021 (UTC)

It's a poignant dismissal of course. I wouldn't put it in the lead myself, but it might reasonably be in here somewhere. (Maybe.) Izno (talk) 02:33, 14 September 2021 (UTC)

The significance, is that a) it is about the topic at hand b) it is be the designer of the topic at hand. I don't see how it could be any more significant. Carewolf (talk) 16:23, 18 September 2021 (UTC)

the cobol of the 90s

I fixed the citation, this is chapter 10 of a book tilted The Unix Haters Group. I disagree in general with that book, I like Unix, but I can agree with what it say about C++, lets be fair, E.W.Dijkstra said something alike about OOP, but I am just going to fix the title of the book.

"It was perhaps inevitable that out of the Unix philosophy of not ever making anything easy for the user would come a language like C++.

The idea of object-oriented programming dates back to Simula in the 60s, hitting the big time with Smalltalk in the early 70s. Other books can tell you how using any of dozens of object-oriented languages can make programmers more productive, make code more robust, and reduce maintenance costs. Don’t expect to see any of these advantages in C++.

That’s because C++ misses the point of what being object-oriented was all about. Instead of simplifying things, C++ sets a new world record for complexity. Like Unix, C++ was never designed, it mutated as one goofy mistake after another became obvious. It’s just one big mess of afterthoughts. There is no grammar specifying the language (something practically all other languages have), so you can’t even tell when a given line of code is legitimate or not." — Preceding unsigned comment added by 187.168.111.50 (talk) 21:56, 19 September 2022 (UTC)

Is this a blog post, or an encyclopedia entry?

This whole entry lacks any sort of cohesion as there is no logical connection between different sections; it's not clear why these poorly collections of mini-rants are compiled into an encyclopedia entry. This whole page, from top to bottom, reads like a poor attempt at gluing together a bunch of random early 2000s blog post-style rants written by a frustrated, mediocre programmer venting off to divert attention from his own mediocrity. There is a pretty good "Criticism" section under the main C++ entry that gives you more information than the entirety of the "C++ Criticism" entry.

So I just have to ask: What is the point of this? Why is this so disorganized? And why does this read like a blog post?! 139.68.209.96 (talk) 01:48, 22 November 2023 (UTC)