To understand the weaknesses of C++?

What can I say about C++?
1. Too weak typification. For example, int x = 0.0;
2. System hederich files is extremely slow, "precompiled headers" and extern template — half-measures.
3. Tangled connection of someone else's compiled code (a DLL for example). Not enough to write a header, you need to compile the lib in General, interesting enough.
4. The STL is extremely fat. Although libc is also "good" — minimal program in Pascal takes a few kilobytes, depending on the compiler, on C — close to one hundred kilobytes. I'm not talking about Linux/MSVC, where libc dynamically linked.
5. A string literal in C++ is the same as the zero-terminated string. When this string you have to wrap any std::string has already been computed when running its length. Why? Why not komprimovat it in EXE schnick?
6. No keywords override/reintroduce. If you change the signature of a virtual method we have to remember where it is overridden by.
7. There are no virtual constructors. "Factory" is a half measure.
8. Clumsily implemented access right "read by anyone, I write only".
9. Explicitly defining methods as inline or non-inline in combination with templates leads to strange effects. When razebanaya leads to complex code, inline harmful (eats CPU cache), when a simple operation with a pointer — on the contrary, necessary. In General, it has long been should be parafia optimizer.
10. A different kind of Ah as a circuit must be implemented on its own. Something like: typedef void (*ProcDoSomething)(int aParam, void* aClosure). The same in Delphi: type ProcDoSomething = procedure(int aParam) of object;
11. If by chance two different modules implementing the same, but one of the preprocessor and the second is a C++ syntax will be a lot of hemorrhoids finding errors.
12. In normal for loop, the counter is mentioned three times. Overall, the place is very oshiblas. For the simple loops I generally have a macro FOR_S (i, 0, n); suffix S means size_t.
13. When refactoring the "internal kitchen" of the object is changing the way of storing links, and changing the code that uses this link. For example: object.buddy.field object->buddy.field, object.buddy().field — depending on, buddy implemented as Buddy& buddy, Buddy* buddy or Buddy buddy().
\r
Yet, I stayed. Me to run.

A weakness of C++ is OOP because it is not
everything else is a lot of rake for people who do not understand how a computer works and/or C++, I doubt that it's really a language problem

>Over time, it became clear that this is not the best combination: unsafe arithmetic pointers and macros are well suited for low level programming, but at a high level, easily lead to errors.
\r
Who asked you to use them? I don't use (or rather it is necessary in 1% of cases).
\r
>exceptions are hard to implement in the compiler, so if we are talking about multiplatform, it's better to forget about them
\r
Let's just say, there is no guarantee that they are safe. Second, they still brake. Thirdly they are really needed in very rare cases.
\r
And what you will desire to write a big program, like MSOffice? He is the way the pros completely written and is very fast. To write software for gamers, where resource problems are acute?
And many problems with the pros not as serious as many like to say, and more problems arise due to the curve design of frameworks for pros. For example, to seek — MFC, and C++ framework I can't bring myself to call.

> multiple inheritance hard to use
Simple pemer: A has two subclasses B and C, from which comes D.
If parent classes have a common ancestor (A), descendant (D) there will be multiple instances of this ancestor. What will work for inherited methods in the General case is unknown. When you cast the pointer D* to A* it is also unclear what he will indicate.
You can fix this by declaring inheritance from A virtual in B and C, but it will be much slower and the initialization of such ancestor have to do with each descendant (B, C, D, and further through the hierarchy), and not only in the direct B, and C. This is not only inconvenient, but does not fit into the PLO. In addition, if A,B, and C declared in a third-party library, such an operation impossible.
> overload using virtual uncomfortable
Can't justify it. I don't think she's uncomfortable. I've always liked.
> exceptions are hard to implement in the compiler, so if we are talking about multiplatform, it's better to forget about them
Forget about them will not work, as they are used in the language (the new operator, for example, uses them). Another thing is that I, for example, they are uncomfortable, but I actually tend to avoid control outputs, and mid functions as, excuse me for being rude, goto statement. In some cases, however, use.
> templates are not the easiest method of generative programming
In my opinion, it is quite simple. Maybe even too much: by using templates it is very easy to inflate the program a lot of similar code.

have already forgotten the epic threads...
\rwww.sql.ru/forum/actualthread.aspx?bid=16&tid=466654

If someone something uncomfortable, something else it can be very convenient.
And Vice versa.