C++ hate

Why do people hate C++? It's a good language.

Comparing to C:
- C++ has RAII, C has not
- C++ supports OOP, C does not
- C programs are full of segfaults and bufferoverflows, C++ programs are not

Comparing to Java
- Java has GC, GC is shit, C++ doesn't have GC
- C++ objects can have destructor
- C++ fast, Java is crap

Comparing to Python
- Both are high level
- Python is very slow, C++ is fast
- Python has dynamic type system, C++ has static type system; dynamic type system causes many bugs, static type system prevents many bugs

Comparing to List:
- Lisp is shit, C++ is not
- GC is shit

Comparing to Haskell
- Haskell is toy language, C++ is not

Overall, C++ is superior language in most cases. In some cases you'd prefer Python, when you need slow program, or Lisp when you need shit program. But in most cases you prefer C++.

C WITH CLASSES is JAVA WITH JUNK.

I think many of C += 1's features are pretty cool, but I wind up using C and doing OO through struct abuse.

C++ is so awesome that it actually has two equally awesome, but different object types. They're so awesome that they can do the exact same things, but obviously not inherit from one-another; because they're THAT awesome.

>>1
Back into Bjarne's anus, please!

>>3
I am unfamiliar with C++, does it have a base type à la Java's Object?

>>5
Yes, void*

dynamic type system causes many bugs

You can make a dynamic/duck type system act like a static type system, the reverse is not true. As an example, consider this ruby code

def foo bar
raise TypeError, "bar must be an Integer" unless bar.is_a? Integer
# Do whatever would be done with bar here
end

Duck typing is best typing.

>>6
I find that difficult to believe, are you saying that it's correct to interpret any instance of a class as a void pointer? If that is true then C++ is truly nonsensical.

>>1
S-expressions are shit, Lisp is great.  GC is great.

>>7

10/10 made me rage.

Check em

>>11
epic dood

>>7
the reverse is not true.
If the language has type-safe unions and operator overloading such as ALGOL 68, you can simulate dynamic typing. The "uniting" coercion automatically coerces values of any type into a union containing that type. The underlying types do not need to be determinable at compile time.
PROC add int = (INT l, r) INT : l + r,
    add real = (REAL l, r) REAL : l + r,
    add string = (STRING l, r) STRING : l + r;
(MODE VAR = UNION(INT,REAL,STRING,CHAR,BOOL);
OP + = (VAR l, r) VAR : CASE l IN
    (INT l) :(r|(INT r): add int(l, r), (REAL r): add real(l, r)),
    (REAL l) :(r|(INT r): add real(l, r), (REAL r): add real(l, r)),
    (STRING l) :(r|(STRING r): add string(l, r), (CHAR r): add string(l, r)),
    (CHAR l) :(r|(STRING r): add string(l, r), (CHAR r): add string(l, r))
    ESAC;
OP +:= = (REF VAR l, VAR r) REF VAR : l := l + r;
VAR a := 10, b := 1.34, c := "Hello", d := "!", e := TRUE;
VAR f := a + b + 2;
b +:= 6;
print((a + b, c + d, c + ", world!", 5 + 10, f))
)
You could overload operators on them, create arrays and structures containing them, pass them to and from functions, etc. Uniting makes it just as easy as using primitives. The transput (I/O) operations, such as the print function, use unions like this to be able to receive arguments of any primitive or array type. In a real "dynamic" library the union would be larger and the operators would have additional cases to handle the invalid combinations. There could also be a generic procedure type like PROC([]VAR)[]VAR in the union but that would require wrappers for the transput functions since procedures in ALGOL aren't printable.

>>1
>C programs are full of segfaults and bufferoverflows, C++ programs are not

>doesn't know how to program C

C++ can edit it's own code? no?
It's shit!
Learn assembly

Compared to everything C++ has outstandingly complicated grammar.

>16
C++ can do things that you can't imagine

>>7
That's just shit. Why would you use dynamic typed language when you use shit pattern like that?

Oh, you must be trolling, nice one!

>>18

Raising exceptions on a bad type is a shit pattern?

>>19
Yes, what if someone wanted to pass an object that behaves like integer but is not really integer to that function. Then it would fail while it should not fail.

>>20
ENTERPRISE QUALITY!

>>7
[quote]having to typecheck at runtime[/quote]
sure is primitive in here

>>22
In Ruby, primitives are objects too!

>>20
Then they should inherit from Integer.

>>24
And why is that? If you want that requirement, you could as well start coding Java. Just let the caller decide if the parameters are ok or not. If it fails then, it's the callers fault. You can write documentation that says function will accept integer, but there's no good reason to enforce that in dynamic typed languages.

>>25
And why is that?
Because "if someone wanted to pass an object that behaves like integer" to a function that only accepts Integers then that object should be an Integer (i.e. inherit from it).

I don't know why I have to explain this to you, it's fucking CS 101, perhaps you should consider doing something else with your life/spare time.

>>26
Java programmer detected!

>>27
So what is your defense exactly, beyond something nonsensical like "Java programmer detected"? Do you honestly have nothing to contribute to this discussion?

>>26
go kill yourself faggot

>>28
In dynamic languages you generally don't care what type the objects are, as long as they work as wanted. Checking if something is an integer is just stupid. What if someone passed in a floating point number?

>>30
What if someone passed in a floating point number?
Then the function obviously wouldn't work, it requires an Integer.

>>31
Now that's stupid.

penis
PENIS
PENIS!!!

I find it hard to believe that in 2012 the vast majority of languages still don't have typeclasses.

It's a good language.
If used carefully. The amount of extra hidden code it generates over e.g. C is enormous. Just look at the asm listing of any moderately complex open-source C++ program and compare it with the original source. A single object instantiation can cause a huge number of constructor calls, and the same for deallocation and destructor calls. Throw in exceptions (pun intended) and the amount of code generated gets even more astounding. (See http://www.openrce.org/articles/full_view/21 for a preview.)

That's the main reason why C++ gets hate from the C crowd. It looks like an efficient language (after all, many features of C++ came from the pseudo-OOP of C) but blindly creating extra objects and classes, introducing lots of virtual inheritance, templates within templates, etc. can make that unrealistic.

And then there's the other side, the ones into "higher level" languages which complain about the lack of features in C++ or its "safety". These are the ones mostly oblivious to real machine operation, care little about efficiency, and can't  count.

There is a tendency, especially among the latter crowd, to push the introduction of new programming paradigms and object architectures, with little thought to their implementation costs. They are, either unknown to or uncaring about, the huge implementation costs that their fancy paradigms and designs cause on real machines. As we approach the 100th anniversary of the digital stored program computer, and looking back at what has happened to "software engineering" and "programming languages" over the years, and the upcoming plateau in execution speeds, perhaps it may be time to realign our goals and models with reality. The research started out in solving real problems like generating mathematical tables and keeping track of people's money, but over the years it has gotten increasingly theoretical, abstracted, and lost track of the real goal: to get things done more efficiently.

>>16
Excluding the natural languages, Perl... and maybe TeX would be even more complex.

>>25,27,29,30
What if the function accesses an array element? What would be the correct behavior of accessing arr["Java is shit"] instead of arr[5]? Wouldn't throwing an exception be the best thing to do?

C++ is an ugly, messy hack on top of C. C programers know that.

>>36
But that throws an exception anyway. No need to write the check the type yourself.

>>32
That might be but it's completely irrelevant, do you have any actual arguments or are you just making noise? All I did was to read the definition of the function, it's clear that it requires an Integer, why this is difficult for you I do not understand.

>39
not sure if trolling...
or just retarted
-.-

>>34
They do, it is called interfaces.

C++ a shit

bampu pantsu

check 'em