c and c++ is gay

char* string1, string2;
string2 is type char.

string class;
So they made a string class but it is incredibly useless, you even end up having to convert to c_str() all the time because basically no other library functions use the c++ class.  You even have to get the c_str() to use the tokenizer(). 

templates:
Never in the history of c++ compilers has there been one that didn't give ridiculously verbose and stupid template error messages.
Also: "<<"!="< <" && ">>"!= "> >"

const keyword:
totally ridiculous when used as a type qualifier for arguments or return values.

ridiculously long compile times for sufficiently large programs.

header files:
Completely stupid. No reason for compilers not to hide this away..

C++ / c interaction:
c++ functions can't be passed as function pointers to c functions.  c libraries and c++ libraries require annoying boilerplate to interact.

virtual keyword:
There's no reason that you would not want to override the parent if you are making a function of the same name.

memory allocation and corruption:
In this day and age, 99.99999% of programs can spare the cycles for garbage collection, even many of the so called "high performance" applications.  Instead you choose to program in a language where a single memory problem can lead to many errors in totally unrelated parts of the program and a difficult debugging time.

Debugging:
run-> crash
no line number or stack trace at all until run in slow as balls debuggers.
Even then, often times the best information they can give you is a useless disassembly of where the problem was.

boilerplate:
All over the place. instead of having a class member functions declared like they are in header files, you end up repeating the class name before each member function.  Header files also share blame for lots of the boilerplate. Also jumping through hoops to mix c/c++

In summary:  bad standard library, poor/no multi-threading support, poor string parsing/manipulation, stupid/pointless keywords, verbose and full of boilerplate.  Performance and memory gains are so slim that the argument for using this antiquated gay language is 999/1000 times because the programmers don't know how to use anything else or because needed libraries or code are already in c/c++.  C is today's equivalent of FORTRAN or punch cards. It served its purpose at the time, and now it needs to die, the sooner the better.

memory allocation and corruption:
In this day and age, 99.99999% of programs can spare the cycles for garbage collection, even many of the so called "high performance" applications.  Instead you choose to program in a language where a single memory problem can lead to many errors in totally unrelated parts of the program and a difficult debugging time.
Ah the good old garbage collection argument, shame that one is usually a piece of shit. If you're argument is solely that the performance vs. code development time isn't worth it, then it is you're job to convince you're manager otherwise. If we look at it from the end-user point of view, then there are only two things that matter; ease-of-use and speed. What other metrics do they care about? They certainly don't care how hard it was for you to program, for the same reason you don't seem to care about the difficulty of writing good garbage collectors; you take it as a given. One thing that people who complain about manual memory management seem to forget, is that good performance isn't so much a question of raw speed, but one of user-friendliness. Fast algorithms, and good memory management can pay for more features or a fancier GUI, or just in not having the end-user pulling his teeth out since the program takes forever.

Besides, the majority of people don't choose  C or C++, but are made to use it.

Debugging:
run-> crash
no line number or stack trace at all until run in slow as balls debuggers.
Even then, often times the best information they can give you is a useless disassembly of where the problem was.
Blame the people who wrote the debuggers not the language.

Debugging:
run-> crash
no line number or stack trace at all until run in slow as balls debuggers.
Even then, often times the best information they can give you is a useless disassembly of where the problem was.

boilerplate:
All over the place. instead of having a class member functions declared like they are in header files, you end up repeating the class name before each member function.  Header files also share blame for lots of the boilerplate. Also jumping through hoops to mix c/c++