Understand the weaknesses of C++?

Question

C++ / C#

Let's try to put everything on the shelves:
70s: Xi's success.
80s-90s: Software got more complex. In order not to greatly complicate the development process, new abstractions were needed:

• inheritance
  
• cast
  
• operator overloading
  
• templates
  
• exceptions
  

Besides, it would not be desirable to lose in productivity.
C ++ appeared - the language of not only system, but also applied programming. Over time, it became clear that this was not the best combination: unsafe pointer arithmetic and macros were good for low-level programming, but at a high level they easily led to errors.
It turned out that:

• multiple inheritance is hard to use
  
• overloading via virtual is inconvenient
  
• exceptions are difficult to implement in the compiler, so if we are talking about multiplatform, then it is better to forget about them
  
• templates are not the easiest way to do generative programming
  

All this is known, but only in the form of such monosyllabic statements, without research and living examples. It would be great if there were such examples. I myself do not professionally develop in C ++, so I turn to the habra community for this

Answer 1

What can I say about C++ problems?
1. Too weak typing. For example, int x = 0.0;
2. The header file system is extremely slow, "precompiled headers" and extern template are half measures.
3. The connection of someone else's compiled code (DLL, for example) is confused. It is not enough to write a header, you also need to compile the lib - in general, there is little interesting.
4. The STL library is extremely fat. Although libc is also “good” - a minimal program in Pascal took several kilobytes, depending on the compiler, in C it approaches a hundred kilobytes. I'm not talking about Linux/MSVC where libc is dynamically linked.
5. A string literal in C++ is the same null-terminated string. When this string has to be wrapped in some std::string, its length is calculated already at execution. What for? Why not compile it into an exe?
6. No override/reintroduce keywords. When you change the signature of a virtual method, you have to remember where it was redefined.
7. No virtual constructors. "Factory" is a half measure.
8. The access right "read by anyone, only I write" is clumsily implemented.
9. Explicitly defining methods as inline or non-inline in combination with templates leads to strange effects. When unpatterning leads to complex code, inline is harmful (it devours the processor cache), when, on the contrary, it is needed for a simple operation with a pointer. In general, this should have become an optimizer's paraffia for a long time.
10. In all sorts of callbacks, you have to implement the closure on your own. Something like: typedef void (*ProcDoSomething)(int aParam, void* aClosure). Same in Delphi: type ProcDoSomething = procedure(int aParam) of object;
11. If suddenly by chance two different modules implement the same thing, but one is a preprocessor, and the second is C ++ syntax, there will be a LOT of hemorrhoids with the search for an error.
12. In a normal for loop, the counter is mentioned three times. In general, the place is very erroneous. For the simplest loops, I generally have the macro FOR_S (i, 0, n); the suffix S means size_t.
13. When, due to the refactoring of the “inner kitchen” of an object, the way the reference is stored changes, the code that uses this reference also changes. For example: object.buddy.field, object->buddy.field, object.buddy().field - depending on whether buddy is implemented as Buddy& buddy, Buddy* buddy or Buddy buddy().
For now, I've been sitting. I should run.

Answer 2

The weak side of C ++ is OOP, because it is not there,
everything else is a lot of rake for people who do not understand how a computer and / or C ++ works, I doubt that these are really language problems

Answer 3

>Over time, it became clear that this was not the best combination: unsafe pointer arithmetic and macros were good for low-level programming, but at a high level they easily led to errors.
Who asks you to use them? I don’t use it (more precisely, it is needed in 1% of cases).
>exceptions are difficult to implement in the compiler, so if we are talking about multiplatform, then it is better to forget about them
Let's just say, there is no guarantee that they are safe. Second, they are slow. Thirdly, they are really needed in very rare cases.
And on what do you deign to write large programs, such as MSOffice? By the way, it is completely written on the pluses and therefore works very quickly. How to write software for mobile phones, where resource problems are acute?
And many problems with pluses are not as serious as many people like to say, and even more problems arise from the crooked design of frameworks for pluses. You don’t have to go for an example - MFC, which the hand does not rise to call a C ++ framework.

Answer 4

> multiple inheritance is difficult to use
Simple example: A has two subclasses: B and C, from which D is derived.
If the parent classes have a common ancestor (A), then the descendant (D) will have several instances of this ancestor. With what inherited methods will work in the general case is unknown. When casting the D* pointer to A*, it is also not clear what it will point to.
This can be fixed by declaring inheritance from A as virtual in B and C, but this will work much slower and the initialization of such an ancestor will have to be done in each descendant (B, C, D and further along the hierarchy), and not just in the immediate B and C. Not only is this inconvenient, but it also doesn't fit into OOP. Also, if A,B, and C are declared in a third-party library, such an operation is not possible at all.
> overloading through virtual is inconvenient
I cannot justify. I don't find it uncomfortable. I've always liked it.
> exceptions are difficult to implement in the compiler, so if we are talking about multiplatform, then it is better to
forget about them they are used in the language (the new operator, for example, uses them). Another thing is that, for example, they are inconvenient for me, but I generally tend to avoid control exits and the middle of a function, like, excuse the rudeness, the goto statement. In some cases, however, I use .
> templates are not the easiest way to do generative programming
In my opinion, it is quite simple. Maybe even too much: with the help of templates, it is very easy to bloat a program with a mass of code of the same type.

Answer 5

have already begun to forget epic threads ...
www.sql.ru/forum/actualthread.aspx?bid=16&tid=466654

Answer 6

If something is uncomfortable for someone, then it can be very comfortable for another.
And vice versa.