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.

>>199

Error: dumbshit detected!

- C was developed in 1973, almost a decade before C++ even showed up.

- The latest revision of C was 2000

- The latest revision of C++ standards was 2011

Derp.

>>201
The latest revision of Fortran was approved in 2010, what are you saying?

>>201
C++ was fucking garbage when it arrived, and it is still fucking garbage now. Deal with it.

>>202
Yes, but everyone knows that anything in existence that even remotely resembles the term "4chan" or any form of rhyme, soliloquy, implication or comparison is complete, indisputable, utter shit.

>>203

Then what would you consider a GOOD language? (inb4 LISP or some other 20-year outdated bullshit language suitable only for wiping your ass with)

>>203
Do you play PC games? If you do, get on your knees faggot and prepare to suck off the C++

>>205
People lived every day under Stalin. He was still a piece of shit asshole and this is objectively a fact. C++ is garbage and you can't handle the truth.

>>206

You haven't given me any valid reasons for your argument that C++ is garbage, nor have you offered an argument in favor of another language as a superior alternative to C++.

Fuck, lrn some shit sometime, would you? It won't hurt you.

>>207
http://yosefk.com/c++fqa/

Please use sage. Your contributions aren't great enough to warrant bumping.

what would you consider a GOOD language?
`
anything but the C++

You haven't given me any valid reasons for your argument that C++ is garbage
grammar
nor have you offered an argument in favor of another language as a superior alternative to C++.
parseable grammar

>>208
I don't use sage because I love to annoy the idiots on 4chan

>>209
Derp-to-English Translation: "This is why no one cares about /prog/"

>>210
Lolwut?

Parsing is fuckballs easy, even hard-coding that sort of shit is relatively simplistic, though a bit more involved. There are over 90000000 C++ libraries to accomplish this sort of shit super-easily.

The only argument I've seen against C++ in this shithole, all probably posts made by the same person(you), is that C++ doesn't have parseable grammar.

>>211
Parsing [C++] is fuckballs easy
I lol'd. There are probably people that believe this, though, that's the sad thing.

>>212

That's because it is, and if you cbf, which most people can't, get a fucking lib, like I said.

"Oh god C++ is so complex!" That's because it has all the features you will ever need, and then some.

As for that site that points out all of the flaws in C++, big fucking deal. Every programming language has its flaws, it's not like your shitty 20 year old irrelevant language is going to have less flaws in usability than C++ has.

People who aren't willing to take the time to learn/understand functionality of such a versatile, mainstream programming language will never be good programmers, plain and simple.

>>208

What kind of shitballs, nix-boon website is that shit? That's probably your shitty website, that's what it is

>>214
Cry more.

>>213
IHBT :(

>>213
>1:44
I bet you were shitposting on /g/ huh faggot

HURDURR LISP IS LIMITED AND HAS NO EXTENSIBILITY
LISP HAS SHIT SYNTAX
LISP = SHIT PERFORMANCE
LISP CODE IS UNMAINTAINABLE IN A GROUP THEREFORE NO ONE SHOULD LEARN IT

>>213
I hate the fact that I mostly agree with this.  I mean, C++ is a convoluted, cumbersome piece of shit, but it really is kind of the best convoluted, cumbersome piece of shit option you have, if you want to write anything useful.  I guess it depends on your definition of "useful," though.

>>218
I hate the fact that I mostly agree with this.
I hate the fact that you mostly agree with that.

>>200
tail calls in Clojure are merely explicit, not non-existent.

At any rate, the sequence abstraction makes it so that you can use all the built in list-processing functions on any kind of data structure, making it very rare to write your own lazy recursive algorithms. Most functions are just map/filter/reduce/partition/mapcat/etc in some combination, even with sets and hashmaps.

>>213
it's not like your shitty 20 year old irrelevant language is going to have less flaws in usability than C++ has.

Virtually everything has fewer flaws in usability than C++ has. (including C!) If you had ever used anything other than C++, you'd know that.

People who aren't willing to take the time to learn/understand functionality of such a versatile, mainstream programming language will never be good programmers, plain and simple.

Did you even read the FQA? People don't conclude C++ is shit out of fucking ignorance. (You're thinking of Lisp.) They conclude its shit from wasting thousands of man hours on it. Have you really never heard, "If you like C++, you don't know it." ?

C can do anything C++ can do and with less "pretend high level" bullshit.

A real high level language can do everything C++ can do WAY better than C++. (except manage memory and other low level shit. But that's what C is for.)

And finally C++'s design is such that you spend all your time thinking about C++ and dealing with C++ and no time solving your actual problem (or even identifying your actual problem.) No human can fit C++ into his head, and programs written in C++ tend to inherit this quality.

Fuck it's like I'm really parroting Linus Torvalds

>>220
tail calls in Clojure are merely explicit, not non-existent.
At least one of the following are true:
1) You don't know what I'm talking about
2) You don't know what you're talking about

>>220
Virtually everything has fewer flaws in usability than C++ has. (including C!)
If you had ever used C and C++ you wouldn't say such nonsense. The first thing I do nowadays when I have to fix some piece of legacy C crap, I make it compile with g++ and then methodically throw out all zero-terminated strings, linked lists and other braindead bullshit from every place that I have to touch. Because in my extensive experience it's a totally worthy investment of effort.

They conclude its shit from wasting thousands of man hours on it.
Yes, a lot of people in IT have mild autism, which makes them latch on an imperfect tool and try to isolate and paint over all of its flaws. C++ attracts such people like 20lb of rotting meat attract flies. Then they come back to their senses with profound mental hangover and write C++FQAs.

C can do anything C++ can do and with less "pretend high level" bullshit.
You are an idiot.

A real high level language can do everything C++ can do WAY better than C++. (except manage memory and other low level shit. But that's what C is for.)
You are an idiot.

No human can fit C++ into his head
Third time is a charm, you really are an idiot!

Fuck it's like I'm really parroting Linus Torvalds
Don't flatter yourself, somehow you managed to omit all and every of his usual points in your rant ^^

JVM can't do tail recursion
Clojure uses JVM
therefore Clojure can't do tail recursion

>>222

It seems like you can't decide whether you think C++ is shit, or C++ is great.

Well, WHICH IS IT FAGGOT?

>>224
True understanding of sepples comes from accepting both as the only truth.

>>223
JVM cannot optimize tail calls
Clojure uses JVM
therefore Clojure can't optimize tail calls

>>223,226
I'm not sure this is a valid argument...
C does not have GC
JVM is written in C
therefore JVM does not have GC

>>227
The general form is not valid, so don't use it at home! But the argument in this particular case is sound.

>>227
It's not stated very well. The details are equally fascinating and boring so I'll spare you. The upshot is you could convert it to iteration but that doesn't suffice to eliminate mutual recursive calls.

>>222
I have to fix some piece of legacy C crap, I make it compile with g++

>>218
I asked some people about their work.
From C++ programmers, everyone uses C++ because they want maximum speed, and either (a) don't like or (b) don't care about the language.

Everyone agress that C++ is overcomplicated and sometimes distract you from the problem you're trying to solve.

EDIT: two interviewees use Qt and somewhat like to program in C++.

EDIT(2): one of them spotted me writing some python scripts, and he moved on to PythonQt.

>>221
neither is the case. "automatic tail call optimization" is basically impossible, so you just be explicit about it with the 'recur' form and Clojure uses constant stack space.

http://clojure.org/special_forms#recur

Since Clojure uses the Java calling conventions, it cannot, and does not, make the same tail call optimization guarantees. Instead, it provides the recur special operator, which does constant-space recursive looping by rebinding and jumping to the nearest enclosing loop or function frame. While not as general as tail-call-optimization, it allows most of the same elegant constructs, and offers the advantage of checking that calls to recur can only happen in a tail position.

In practice it makes almost no difference because you tend not to write non-lazy (manually) recursive functions.

>>222
If C is bothering you, you're solving the wrong problem with it. And the problems that C isn't good at solving are generally better solved by things higher level than C++. The advantages that C++ has over C only seem impressive if those are the only two languages you've used. C++ is still woefully inadequate at abstraction, and the price it pays for the meager capabilities it does have are glacial compile times and ridiculous complexity. I'm not just overusing the word "ridiculous." C++'s complexity deserves ridicule.

Everything high performance is going "data-oriented" these days anyway, where as much as possible is done on the stack and lots of attention is being paid to how blocks of memory fit into cache and complex object models are being thrown out the window.

The desire for optimization and abstraction at the same time is essentially stupid. Optimization means specified and inflexible. Abstraction means preventing implementation details from affecting your design.

It's like, if I'm gonna have desert, I'm gonna eat a bunch of fucking ice cream. I'm not going to have have sweetened tofu. It's like you look at C and it's tofu, right? And you're like, "no, this isn't sweet enough!" The solution is to go to a different fucking restaurant.

>>232
desert
delicious cacti

"data-oriented"
true

>>232
In practice it makes almost no difference because you tend not to write non-lazy (manually) recursive functions.
Fuck you, bitch! I frequently use continuation-passing style, instead of frigid single path return.

>>232
In practice it makes almost no difference because you tend not to write non-lazy (manually) recursive functions.
But that's wrong, not all tail-recursion is tail-recursive:
(define (remove-duplicates xs) ; removes the consecutive duplicates in a list
  (cond ((or (null? xs) (null? (cdr xs))) xs)
        ((equal? (car xs) (cadr xs))
         (remove-duplicates (cdr xs))) ; tail recursion
        (else (cons (car xs) (remove-duplicates (cdr xs)))))) ; no tail recursion
And there are more reasons why loop/recur are just an ugly workaround for proper tail calls.

>>236
It's like you don't even know what ``tail position'' means.

>>235
much more often than not CPS can't benefit from tail calls...

at any rate, it's all silly because with lazy sequences, you so rarely write recursive functions. that's what I keep saying.

It's way more idiomatic Clojure to write


(def factorial #(reduce * (range 1 (inc %))))

than it is to write

[code]
(defn factorial [n]
    (loop [cnt n acc 1]
       (if (zero? cnt)
            acc
          (recur (dec cnt) (* acc cnt)))))
[code]

Seriously, the lack of laziness in a lisp is a bigger deal breaker form e than the lack of automatic tail call elimination. Not to mention immutable sets/vectors/associative arrays.

>>238
Clojure is useless for anything but factorials.

Also
(inc %)
wtf is this obfuscation?

>>239

I am not a clojurer, but I would guess that it stands for the the first argument, so you can express things without names, in the convenient way one would be able to in a stack based langauge.


/factorial {
  inc 1 exch range {mul} exch reduce
} def