Why is C++...

...so bad? Why does it have such a bad reputation?

I'm an experienced C++ programmer and, while the language has warts, I can't understand the reason for the enormous amount of criticism against the language.

I'd like to hear the honest opinions of /prog/rammers in this regard.

>>40
Its also what appears at the very beginning of the introduction (page 2) of R⁵RS. But you knew that, and you read your SICP too, right?

>>40

simplicity, clarity of form, absence of clutter.

it is a design principle seen over and over again in industrial product design, modern architecture, etc

>>41

Epigraphs appear in many places, sometimes to help further legitimize an idea. This doesn't readily imbue them with any practical sense at all.

>>43
When your favorite language's full specification, formal syntax and denotational semantics, and documentation of basic libraries fit together in 50 pages we can talk.（　≖‿≖）

>>9

madness?

Madness!

THIS IS SEEPLES!

>>24
The major problem with C++, in my opinion, is the toolchain. Many problems you've cited would be much better handled if the compiler did it's job a little better, specially when issuing error messages to the user.
Anyone who says this instantly reveals how little they understand about why C++ is shit.

erik naggum says it best.

http://www.xach.com/naggum/articles/3103356827666810@naggum.no.html

every C++ programmer I know (including myself, for a few years) turns into a insecure, paranoid, dishonest, closed-minded jerk.

>>46

It's really difficult for a C++ compiler to issue good error and warning messages to the user because the C++ grammar is so freken weird.

I just realized that you aren't allowed to define types when declaring a return type in C++, but you can do it in C. The following is valid C:


struct {
  int w;
}* f() {
  return 0;
}

>>49
Only because ancient C standards assumed that int was the default return value, and could be omitted. This behaviour is highly deprecated nowadays and should never be used (try -Wall).

>>50

Nah, what's going on in that code there, is, a function f is being defined. f takes no arguments, and f returns a pointer to a struct that contains a single int member called w. So if f returned a valid pointer, you could do:


f()->w = 5;
printf("%d\n", f()->w);

But the structure that f returns a pointer to has no name.

>>24
It's like you said, C++ inherited many things from C, but simplicity. If you look at C, it's pretty minimalist and straightforward. That's why there's new languages aiming to be a C++-- (Java, D), and many programmers (and code) restricted to simpler subsets of the C++ language. A good toolchain really can help, but is it really necessary?
Look at the facts, C++ is old, overcomplicated and ugly. There's so much better languages out there that C++ nowadays is just an alternative to C when coding low-level, performance sensitive or time critical functions.

C++11 fixed some quirks and added some interesting stuff, but C++ needs a lot more to become a lovely language.

>>40
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” -- Antoine de Saint-Exupery

It was nice to know picolisp.com
specially http://software-lab.de/radical.pdf

C++ is a minimalist tight language that's completely sane and logical. It was made by a god. I am the ordained shit poster of the east.

>>54
tight
boner

>>55
you get excited way too easily. you need some discipline :3

>>56
:3
boner

>>57
boner
boner

dickanii

>>44
Good. Thus we might exclude every modern programming language, including C, Java and almost every scripting language out there.

How old are you, by the way?

>>47
I've read it elsewhere, and commented on it. I'll not repeat the entire argument, but just restate that this guy must be living on a reality bubble. He abuses terminological ignorance ("epistemological process"), unwarranted personal judgements and assertions ("C++ is a language strongly optimized for liars and people who go by guesswork and ignorance"), and even poetic verbosity ("C++ has taken premature optimization to the level of divine edict"), instead of trying to analytically pose arguments in his favor.

In other words, his text has a particular effect on people which are already influenced and particularly biased to accept that sort of criticism -- that's exactly the goal of his text. It is not to help forming an opinion, but rather exalt and praise an already present one, inside people without the verbal talent to express it the way he did.

And, as most teenagers, he doesn't even bother writing properly, and jot funky rebel signatures in his emails. In plain English, the guy's simply an immature neckbeard. Too bad he claims himself to be a Lisp hacker: it just helps further mar the image of the average Lisp programmer, in detriment of the very few sane (and socially capable) ones.

For good C++ criticism, Yossi Kreinin's FQA is a much better read, in every aspect. Specially because Marshall Cline's FAQ, its antagonist, is a terrible read: he is arrogant, yield unfunny jokes, and sometimes outright lie to the reader. He wears that damned sort of "expert aura" which has also contributed for the bad reputation of C++, making it sound as a language for pedants and help stratifying the programming community into castes.

>>48
Not really, the compiler already detects such cases. True, the C++ grammar is much harder to parse than the C grammar, but, fortunately or not, that problem has already been solved. GCC, for example, is particularly retarded: ever noticed the "each undeclared identifier is reported only once for each function it appears in" (which happens in C and in C++) messages it spits you, sometimes uselessly consuming three lines in your screen? The message's intent is probably to avoid build log pollution, but that's exactly what it does. This is just an example: that's the compiler team's way of being "helpful" to the programmer.

>>52
The fact that most C++ programmers restrict themselves to some subsets of the language is actually necessary, and rather intentional. Concerning the fact that the language contains a lot of different thinking models imbued in it, it is good that a program is itself restricted to a couple of these models, instead of attempting to apply all of them in the same program, which would be awkward and difficult to understand. Whether a language with such characteristics ("multiparadigm", in buzzwords) is itself "good", is just another matter.

Uglyness and complications are highly subjective factors. The C++ syntax I consider ugly is related to the standard libraries and to legacy C constructs, but in general I find it much pleasant to read than Java or Python code, for that's sake. The C++ syntax fits quite well for its purposes.

I like minimalism. I enjoy the idea of taking instead of putting, of having less instead of more. It fits my style, but that's not the point -- I'm not applying personal judgements to a piece of work as it appeals to me, but rather try to evaluate it as it is, in the context where it was intended to fit in. C++ was not meant to be minimalistic; stating it is not so is just reiterating a known fact, and remarking that it is (therefore) bad falls within the scope of subjectiveness and personal opinion.

C++ is indeed old: thread support just came in with C++11, and it still lacks a lot of important things for proper application development, such as networking support. This is, nonetheless, a characteristic of the (official) standardizing process, specially because one of its goals is to provide a lowest common denominator between all platforms the language is intended to target. It follows the C mentality of "if PDP-11 doesn't have it, C++ doesn't have it either". Most C programs are non-compliant, as most C++ programs are.

Aside the entire toolchain problem, one point also worth noticing is that there is a relative lack of good libraries for C++ (and there ain't nothing such as POSIX for further extend the possibilities). Boost is always there, but I personally don't consider it to be a good library.

There's nothing wrong with C++, it's decent at what it was designed to do. I.e., to be an OO superset of C. If you need an OO language that is a superset of C, then you should use C++ (or Objective-C), otherwise there are better languages out there.

>>61
There's nothing wrong with brainfuck, it's decent at what it was designed to do. I.e., to be a turing tarpit. If you need a useless language that is a turing tarpit, then you should use brainfuck (or befunge), otherwise there are better languages out there.

>>62

Is /prog/ particularly retarded today, or just trolling?

Is >>63 particularly retarded today, or just trolling?

>>61
Endless ignorance. Do you seriously think that adding OO to C could only be done by C++ retardation? What the fucking fuck.

>>60


fyi epistemology is the branch of philosophy that is about how knowledge is obtained. C++ encourages you to use your magic prediction powers to be able to tell what the program will look like before you write it. That's what he was complaining about. Any language that isn't good for exploratory programming isn't good for programming at all. And that's the essence of 'premature optimization is the root of all evil' It is IMPOSSIBLE to make something both flexible and optimized. You have to optimize later, when the design is settled. C++ does not allow this attitude.

And this DOES affect personality. Someone who prides himself on his ability to anticipate needs is known as "codependent", and it's an unhealthy way to live your life. It comes along with intense fear of vulnerability and distrust of anyone around you to take care of themselves. The parallels that these traits have with the semantics of the C++ language and how it is idiomatically used are pretty obvious, I think.

And yeah, I'm projecting my own experience. But I've seen it in my peers and others on the internet (including Naggum) have seen the same pattern. Some programmers can write code all day without it affecting the way they think, but the parallels between how C++ works and genuine psychological dysfunction don't speak well for the language either way, I think.

>>60
Uglyness and complications are highly subjective factors.
related to the standard libraries and to legacy C features

No.

template <typename T>
bool write(const T& obj) {
    typename T::iter i = obj.iter();
    // ...
}
Is typename really necessary? Oh wait. There's this nice feature auto type inference in the C++11.

template <typename T>
bool write(const T& obj) {
    auto i = obj.iter();
    // ...
}
auto type inference

template<class A, class B>
auto add(const A &a, const B &b) -> decltype(a+b) {return a+b;}
If this isn't ugly, at least it's verbose.
Seriously, C++ is going to break.

>>66

I know what epistemology is. I know about every term used in the post means. Many people don't, however, and using such terms with almost no adequate context for that just creates communication noise. Communication noise is both a consequence of bad communication skills, and of intentional blabbery in order to induce confusion, excitement and anger, disguised as intellectually profound reasoning. The point he possibly wished to express in the post is deeply buried behind an intentionally confusing verbosity -- even comparable to the "C++ complexity" he so much condemns, if you permit me an alias.

In other words: what he really intended is to cause public commotion and exasperation, and to impress the audience. Gain the argument through aesthetics. Or at least that's the way I judge it, since by no means I take the guy for a stupid man.

Apart that, I agree with some things you've said. The language induces some behavioral patterns on people, as much as human languages do that (that is called "Sapir-Whorf hypothesis"). However, do other OO languages induce "better" behavior and mental discipline than C++? Do they differ at all? C++ is not much different from other OO languages. As it is already clear from what I've been arguing, OO itself numbs people down to their bogs, but that's just my opinion.

I don't see such a need of foresight in C++, or, if I do, I don't see why it differs from other object-oriented languages. The need of such an ability -- to foresight what your needs will be, before even having any sketch of your layout --, assuming it exists, is bound to the object-oriented mentality itself, not the language. I'm not particularly fond of the OO mentality itself, but C++ can't be blamed for it. What I see is that everything in the object-orientation world is difficult, but C++ doesn't contribute to make it harder. Design issues are bound to the paradigm, and the language -- by offering "too much" in any regard -- can't make it more difficult. For example, I don't consider whether a reference or a pointer will be used to be a design decision in itself, neither whether some symbol will be in some namespace or another (since the language allows you to do mostly anything you want to do in many dimensions), and so on. I consider that people who lose themselves in these problems, and need some language constraints to keep them in track, have failed to grasp the greater design problem of their projects.

I will make an exception: weak-typed languages (Python comes to my mind), where you don't have to explicitly declare types and they may vary in the runtime, ward off a lot of problems you usually have in OO. Duck-typing allow you to boost enormously your code, writing future-compatible code without the need of even specifying what future code needs to do in order to communicate with your design: they just need to provide a compatible interface. But they do introduce another gigantic pack of problems which are automatically solved in strong-typed languages, and I suppose you are well aware of those problems. Well, C++ has simply opted for one of this problem/solution pairs.

>>67
automatic type inference is my new waifu

>>69
Haskell
- Just like C++, Haskell is very hard to learn, and takes years to master. Things like Monads, Functors, Monoids, Higher-Order Types and a myriad of morphisms are hard to understand, especially without mathematical background. So most programmers probably don't have the ability or will to learn Haskell. Learning Haskell's syntax, libraries, functional programming techniques won't bring you closer to understanding: the true path to understand Haskell lies through Monoid-Functor-Applicative-Arrow-Monad. And even if you mange to learn Haskell, programming it still hogs a lot of brain resources, which could have been put to something more useful than just showing off about how clever you can be. "Zygohistomorphic prepromorphism: Zygo implements semi-mutual recursion like a zygomorphism. Para gives you access to your result à la paramorphism." -- HaskellWiki
- Haskell is slow and leaks memory. GHC's inefficient stop-the-world GC does not scale. A good understanding of evaluation order is very important for writing practical programs. People using Haskell often have no idea how evaluation affects the efficiency. It is no coincidence that Haskell programmers end up floundering around with space leaks that they do not understand. "The next Haskell will be strict." -- Simon Peyton-Jones
- Haskell's API lacks higher levels of abstraction, due to absence of variadic functions, optional arguments and keywords. Macros aren't possible either, due to overly complex syntax of Haskell. API documentation is very lacking: if you want to use regexes, you start at Text.Regex.Posix, seeing that =~ and =~~ are the high level API, and the hyperlinks for those functions go to Text.Regex.Posix.Wrap, where the main functions are not actually documented at all, so you look at the type signatures, trying to understand them and they are rather intimidating (class RegexOptions regex compOpt execOpt => RegexMaker regex compOpt execOpt source | regex -> compOpt execOpt, compOpt -> regex execOpt, execOpt -> regex compOpt where). They are using multi-parameter type classes and functional dependencies. The signature really wont give you any clue to how to actually use this API, which is a science in itself. Haskell is a language where memoization is a PhD-level topic.
- Haskell programming relies on mathematical modelling with type system (a version of mathematical Set Theory). If one does not use the type system for anything useful, it obviously will be nothing but a burden. Programs are limited by the expressiveness of the type system of the language - e.g. heterogeneous data structures aren't possible w/o reinventing explicit tagging. All that makes Haskell bad for prototyping or anything new, due to need of having design document with all types beforehand, which changes often during prototyping. Any complex project have to reinvent dynamic typing. For instance, Grempa uses dynamic typing because the semantic action functions are put in an array indexing rule and production numbers (Ints) to functions, and they all have different types and so can not be put in an ordinary array expecting the same type for each element.
- The IDE options cannot be as good as those of dynamic programming languages, due to absence of run-time information and access to running program's state. Haskell's necrophilia forces you to work with "dead" code. Like other static languages, Haskell isn't well-known for its "reload on the fly" productivity. No eval or self-modifying code. Haskell code can't be changed without recompiling half of application and restarting the process. GHCI - is the best Haskell's interactivity can get, and still wont allow you to change types during runtime, while the single assignment semantics prevents redefinition of functions. As said Simon Peyton-Jones, "In the end, any program must manipulate state. A program that has no side effects whatsoever is a kind of black box. All you can tell is that the box gets hotter."
- Type system produced compile-time and link-time errors are distracting and make it harder to run and test your code, while type-checking isn't a substitute for testing, it is about correspondence to mathematical model, which has nothing to do with correctness - i.e. two numbers can be integers, but their quotient can still result into division by zero. Even though you may hear strong static-typing advocates say, "When your program type-checks, you'll often find that it just works", this is simply not true for large, intricate programs. Although type-checking may help you find model-related errors, it is not the same as testing.
- Absence of dynamic scope, implicit open recursion, late binding, and duck typing severely limits Haskell, since there are things that can't be done easily without these features: you can't implement dynamic scope in general (and be type-safe) without converting your entire program to use tagged values. So in this respect, Haskell is inferior to dynamic typing languages.
- Haskell makes it easy to write cryptic programs that no-one understands, not even yourself a few days later. Rich, baroque syntax, lazy evaluation and a tradition defining an operator for every function - all help obfuscation a lot. As a general rule, Haskell syntax is incredibly impenetrable: who in their right mind thought up the operators named .&., <|> and >>=?

>>67

I agree with you there. typename is simply a cue for the parser to be able to parse the grammar, useless to the programmer. Template parsing yields ambiguities, and the way C++ solved it is hinting the parser with extra tokens to avoid reduction conflicts. This is one huge wart in my opinion.

Nonetheless, G++ and MSVC are able to parse the code without the typename keyword prefixing a dependent type whatsoever. Maybe these usages will futurely disappear.

Some choices for keywords in C++11 sounds ridiculous to me too. nullptr, decltype, typename and more. This obsessive need to have a single-pass compiler (forcing the language to be polluted with non-intuitive syntax) is also a botch.

However, when people don't like something, they should manifest the discontent in order to yield changes. In my humble opinion, C++11 could have been much better if the community -- not the language, not the technical needs -- behaved better during these ten years the language gained popularity, both C++ aficionados and C++ haters. Aficionados behave as if they were programming gods, praising complexity and further legitimizing the criticism the C++ haters themselves shoot against them.

>>71
No.
While there's ridiculous choices, they were mostly proposed along the years by some expert programmers. One example is how Modern C++ Design and Effective C++ lead to some practices, libraries and idioms that heavily influenced the TR1. Even with enough care, some verbosity and weird constructs will never be erased of the C++ language.

I really believe that people need redesign and create a completely new language. D and Go were nice attempts, but don't fit my tastes yet.

But I don't think this is a big deal. C++ looks bad just because there are more interesting alternatives, but they still can't fit the high-performance computation marketshare.

Here at my (CS) department 80+% of lab mates use C++, in various fields: machine learning, image processing, database extensions, language processing, fluid dynamics... because they demand speed. The other 20% mainly use Java/Ruby/Python when working on not so sensitive apps, like software engineering tools and HCI prototypes.

The engineering dept. people here pretty much use MATLAB for everything, and some prefer Fortran for high performance computing.

It's sad that functional and logic languages almost have no users here, despite their high level abstraction and power. It was an interesting fact that people that learned these “strange” languages (Haskell, Prolog, LISP...) well usually took them to heart and did very fruitful things like 3D games and SQL query engines.

>>68
the thing is, C++ basically invented modern, typical OOP. Java and C# in particular base their models directly on C++. Languages like Smalltalk and CLOS were perhaps in the background, but, funny enough, these languages are both all about duck-typing and extensible, future-proof design as a consideration above and beyond performance.

In a general comparison of CL and C++ you see a reoccurring pattern. It isn't that C++ made a different, arbitrary choice of problem/solution pairs. It's that C++ ALWAYS chooses the option that corresponds to premature optimization. And CL isn't even the best example, just a convenient reference point.

Multimethods: flexible and generic.
vtables: optimized

lambda: flexible and generic
classes: optimized

garbage collection: flexible and generic
the stack, shared_pointer, etc: optimized

numerical tower: flexible and generic
int,float,double, iirc STL has not standardized a bignum class yet: optimized

macros, essentially a "scriptable compiler": flexible and generic
leave the compiler alone so it can micro-optimize better: optimized

So, if C++ made any arbitrary choice of problem to tackle, it was to design a language that is easy for compilers (human or non, to borrow a Paul Graham-ism) to optimize, not to make it easier for programmers to write better software. This isn't in and of itself a problem. It's what C does. The difference is that C is honest about what it is and what it's for. It's a language for implementing a solved problem in an efficient and portable way. C++ OTOH has a pretense that it's not just fancy assembly.

>>74
the thing is, C++ basically invented modern, typical OOP.
You have to be joking. Have to be. Have you ever used those other languages? They have actual features like reflection and encapsulation. C++ showed everyone one think with crystal clarity: how not to do anything.

>>74
multiparadigm + optmization + C compiler → C++

C++
http://img.0chan.ru/b/src/13233783418939.jpg

>>72

Indeed. But think again: what is an expert programmer for you? I won't completely discredit the authors you've mentioned, but I wouldn't really call them "expert" either -- specially because, seeing some code they augment, I wouldn't use nor recommend some of the practices; I wouldn't hire them for my team. These authors respond more to the financial interests of the companies which support them than to the community of which they claim to make part. They drive the development of things like Boost, turning them into models to follow, naming them "expert" code -- and in the same time offering advice and consulting at expensive fees; a very interesting market strategy indeed. It seems even natural for me that these people will separate themselves from the crowd, and protect their reputation as "experts".

Besides, while Java, C# and others are leading technologies owned by the same companies which pay the "experts", C++ is rather owned by no one -- why would a company invest on something it doesn't own if it can invest on it's own technology, which is already deployed and already popular in the language battlefield? It could be argued that the "experts" have even intentionally worsened a number of things out in C++11, but I won't go too far as to sustain this idea. The fact is that C++ is of few commercial interest compared to technologies which are so aggressively pushed by companies nowadays.

Expert programmers are programmers with good experience, which have good knowledge of the technology they use, and which have passed through some tough situations during their careers. They have sensible notions regarding many aspects in a project, even if they wouldn't agree on every such aspect. And there are a lot of experienced programmers out there: not only those inside the C or C++ fandom, but in particular there are a good number of them in these groups. There are a lot of people which could have done much better if they just expressed their points objectively and neutrally, instead of bashing themselves senseless with petty discussions regarding specific "tastes".

C++ is a package of FUD, well wrapped in a foil of vanity.

Ultimately, C++ designs can be simple and tidy. Even if the problems they attempt to model are complex, the solutions can be simple, easy to use, easy to understand, easy to maintain. They can be nonetheless extremely cluttered and complicated, and even "wrong" in a OO perspective, specially because OO is a design pattern particularly difficult to implement: writing bad code is not a problem specific to C++ itself.

>>77
ru
Back to your russian imageboard.

>>78
C++ is a package of FUD
I wanna be a FUD
http://en.wikipedia.org/wiki/Female_urination_device