Dark Side of C ++

Recently, The article <The Dark Side Of C ++> has been widely reproduced. As a programmer who eats C ++, you should download it and read it carefully. In general, the summary is quite comprehensive. Due to the limitation of personal knowledge, I divided my personal knowledge into three categories: I did not agree with them, and I felt that they were not on the dark side, however, it is hard to understand, and the other type of research needs to be studied at a later time.

I. disagree

• The constantly changing standards force us to constantly update existing code.
  The author has listed several issues that do not have a significant impact (Circular Variable scope, header file suffix, and namespace ). In addition, the occasional compromise should also be made for the sake of standard progress.
• The following is an example of Changing Styles: Old and busted:
  For (int I = 0; I <n; I ++)
  New hotness:
  For (int I (0); I! = N; ++ I)

  Is there a problem? Does anyone use the second method?

• Auto_ptr is bad.
  Now, you don't need it, and you should have reached a consensus after the smart pointer has joined the C ++ 0x family.
• Iterator may be invalid.
  I feel better, but I have never encountered too many problems;
• Iterator has no knowledge of container.
  I think this is an advantage of STL design. The iterator decouples the algorithm from the container.
• Vector: at checks the boundary, but operator [] does not.
  Good. There are two options available.
• Virtual function calls in constructor and destructor may call virtual functions of the base class, or even pure virtual functions.
  This is not so dark. It should be common sense not to call virtual functions in constructor and destructor. Isn't this problem in other languages?

2. Share the same feelings

• Template compilation errors are complicated, probably because the iterator type is incorrect. The destroyed C ++ 0x proposal does not know whether it can solve this problem.
• Code written in C ++ is not easy to read, function overload, operator overload, virtual function redefinition, type redefinition, macro definition, etc, the real face of the Code is strictly hidden behind me. (Of course, this is also for abstraction and consistency), a few examples: string a ("blah"); // defines a string object
  String a (); // declare a function
  
  A & B // If & is not redefined, it is short-circuit computation. If it is overloaded, both of them may need to be calculated.
  
  Typedef OtherType & Type;
  Type a = B;
  A. value = 23; // If the typedef is not displayed, the ghost knows whether the value of B will be changed.

  In addition, baz = foo-> bar (3); the infinite possibilities behind such a simple line of code fully reflect the hard-to-read features of c ++ code.

• The discussion about why cin typecast to void *, rather than bool, highlights the extreme strength of the sword in C ++-it is easy to hurt itself if you do not have a fire.
• An exception should not be thrown in the destructor. I used to only know one reason-that is, The Destructor is called during the stack expansion process of the previous exception and an exception is thrown, causing the program to exit. But here I think it is more convincing: When the delete [] array is used, the previous object structure throws an exception, causing memory leakage of other objects in the array.
• The initialization sequence of class members is determined by the defined sequence, rather than the sequence in the initialization list-this is indeed a big confusion, it also brings a lot of bugs-Because C ++'s behavior is counter-intuitive.
• In function calling, the pointer passing method clearly tells you that the function may change this parameter, but the reference is not so obvious. The syntax is the same as the value passing method, you can also change the parameter value.
• C ++ is too powerful and flexible, and many people cannot control it well-too many complicated feature sets. To use it well, you can read a doctor ~~~
• The prefix ++ overload syntax is operator ++ (yourtype &). To distinguish it, the postfix overload syntax has a dummy int parameter: operator ++ (yourtype &, int dummy ).
  Although I don't have a better way, I admit it is silly.
• Different allocator containers cannot interact with each other. This is understandable because allocator in STL is part of the container type, different allocator causes different container types-but this requires us to consider whether it is appropriate for STL to provide allocator in this way.
• Map operator [] automatically adds elements if they do not exist.
  Compared with find and insert, operator [] is too convenient. This convenient temptation has indeed caused a lot of trouble.
• You have to write >>> in the template. Because> is already in use.
• There is no need for exception. How to make good use of exception is a very big and deep topic. You can have a doctorate degree at the University. Resource leak and deadlock are common problems in exception security.
• Delete [] can well process arrays that degrade to pointers. If it is a class, calls the Destructor s, because the number of array elements can be passed through sizeof (memoryblock) /sizeof (type.
• New [] may cause int overflow, for example, new double [0x8000000] = malloc (8*0x80000000), beyond the int expression range ~
• Initialization of local static variables is NOT thread-safe-this problem is especially common in single-piece mode in multi-threaded environments. Generally, it can be solved using lock, but it is effort-consuming to lock each access, therefore, a double-check lock method is used. However, the reorder caused by Compiler Optimization may also cause thread insecurity. volatile or memory barrier must be used to prevent optimization. This estimate can be used to write another article.
• The base class pointer is used to operate the array of the derived class. p ++ does not point to the next element, but to an inappropriate memory address.
• If you have a function name in the derived class and the function name in the base class are repeated, functions in the base class will be hidden in the derived class even if the function prototype is different.
  This is indeed too much! Why?

Iii. Future Research

• Has C ++ made any major changes to the namespace?
  This estimate is about the design and evolution of the C ++ language.
• Writing a good library in C ++ is basically impossible.
  I have seen many people, including cool people, say this, but I wonder if I have provided a list. The shortcomings in C ++ make it impossible to write a good library. Which languages are acceptable? Why?
• We should not throw an exception in the constructor, because: Exceptions in constructor don't unwind the constructor itself.
  I don't quite understand this. As far as I know, throwing an exception in the constructor is a method in which the constructor reports an error because the constructor itself does not return any value.
• When an exception is thrown: Does not even clean up local variables!
  I don't understand. Isn't RAII memory management by using the local object structure.
• Assert (s [s. size ()] = 0); works if s is a const std: string, butis unde incluned if it is not const
  I tried it on VC2008. No problem. Why?
• If you call delete when you shoshould have called delete [], the pointer wilbe off by sizeof (int), leading to heap resume uption and possibly code execution.
  Don't understand.
• If you call delete [] when you shoshould have called delete, some randomdestructors will be called on garbage data, probably leading to code execution.
  Why, delete [] will calculate several elements in the array, and the answer should be 1, so there should be no question-this may be related to the previous answer.