The dark side of C + +

Turn from: http://www.kuqin.com/language/20110522/91699.html

Recently an article <the Dark Side of c++> in the popular spread, as a C + + as a meal for the programmer, or should be downloaded to read it well. In general, it's a pretty complete summary. As a result of the limitations of personal knowledge, I read it into three categories: one is that I do not think that the dark side, a kind of deep empathy, suffer from it, and the other is not understood, need to have time to study in the future. One, not to disagree with the changing standards, forcing us to constantly update the existing code.
The author lists several points in fact that are not very significant (scope of the loop variable; header file suffix; namespaces). And, for standard progress, occasional compromises should be made. The changing style, as the author has cited, is:

Old and Busted: for
(int i = 0; i < n; i++)
New hotness: for
(int i (0); I!= n; ++i)

Is that a problem?  Does someone use the second way? Auto_ptr is rotten. Well, you don't have to do it, and recently, after the smart pointer joins the c++0x family, it should be agreed that iterator may fail. This I feel good, did not encounter too many problems, iterator to container no knowledge. I think this is an advantage of STL design, through iterator decoupling algorithm and container. Vector::at will do boundary checks, and operator [] will not. Well, that's good. Two choices the constructor and the virtual function call in the destructor may call the base class's virtual function or even a pure virtual function. It's not that dark. It should be common sense to always call virtual functions in constructors and destructors, and there is no other language that has this problem. two, deep empathyThe avalanche of compiler errors in the template, behind tedious errors, may be simply the wrong type of iterator. The dead C + + 0x proposal is not sure if this problem can be resolved. The code written in C + + is not easy to read, function overload, operator overload, virtual function redefinition, type redefinition, macro definition and so on, the real face of the code is tightly hidden behind. (Of course, this is also for abstraction and consistency), a few examples:

String A ("blah"); Define a String Object
string A ();//Declare a function a

&& b//If && is not redefined, it is a short-circuit calculation; but if overloaded, then maybe both of them have to compute the

typedef. othertype& Type;
Type a = b;
A.value = 23; If you don't see the TypeDef, the ghost knows that B's value will be changed.

  In addition,  baz = Foo->bar (3); Such a simple line of code behind the infinite possibility, but also fully embodies the C + + code difficult to read the characteristics. About the CIN why typecast to void*, rather than bool discussion, highlighting the C + + Sword walk slant situation-not the heat, a trick careless will easily hurt itself. No exception should be thrown in a destructor, and I know only one reason-that is, calling a destructor and throwing an exception during the stack expansion of the last exception can cause the program to exit. But here's what I think is more convincing: when the delete [] array, the preceding object destructor throws an exception, causing the other object memory in the array to leak. The initialization order of class members is determined by the order in which they are defined, rather than by initializing the order in the list-which does cause a great deal of confusion and a lot of bugs-because C + + behavior is counter-intuitive. In the function call, the way to pass the pointer is more obvious to tell you that the function may change this parameter, and the reference is not so obvious, syntax and the same as the value call, but also can change the value of the parameter. C + + is too strong, too flexible, many people can not be very good control-too many complex feature set, to use it, you can read a doctor ~ ~ ~ Prefix + + overload syntax is: operator++ (yourtype&), in order to distinguish between The overloaded syntax for postfix has a dummy int parameter: operator++ (yourtype&, int dummy). Although I do not have a better way, but I admit it is really silly. The same container, because the use of different allocator can not be interactive, this is understandable, because the STL allocator is part of the container type, allocator different types of container type- But this has to make us think that it is not appropriate for STL to provide allocator in this way. Map's operator[] automatically adds elements, if they do not exist. Because it is so convenient compared to find and insert,operator [], this convenient temptation does cause a lot of trouble. In the template you have to write >> written > >. Because the >> is already occupied. With no exception, how to use good exception is a very big, too deep topic, can open a doctorate in the university. Among them, resource leak,deadlock is a common problem in abnormal security. Delete [] is a good way to deal with an array that is degraded to pointers, and if it is a class the call will call the destructor s, because the number of array elements can be passed through sizeof (mEmoryblock)/sizeof (type) is obtained. New [] may cause an overflow of int, such as: New double [0x8000000] = malloc (8 * 0x80000000), exceeding the expression range of int, and overflow ~ Local static variable initialization is not thread-safe-This problem is a single piece pattern in a multithreaded environment is particularly common, can generally use lock to solve, but each access lock is more laborious, so will use a double-check lock, but this way due to compiler optimization caused by reorder, also thread is unsafe, need to use volatile, or memory barrier to prevent optimization. This estimate can write another article. Manipulating an array of derived classes with a base class pointer, p++ not referring to the next element, but to an inappropriate memory address. If you have a function in a derived class with the name of the function in the base class repeat, even if the function prototype is not the same, the function in its base class will be hidden in the derived class. This is indeed a bit excessive. What's the reason behind it?   third, future researchAre there any big changes in C + + about the name space? This estimate is to check the design and evolution of C + + language, it is impossible to write a good library in C + +. I see a lot of people, including the Bulls have said this, but I do not know whether there is a list, C + + in those shortcomings so that the good library to write the impossible, which languages can, why. We should not throw an exception in the constructor because: exceptions in constructor don T unwind the constructor itself. This is not quite understood, as far as I know, throwing an exception in a constructor is a method of a constructor error, because the constructor itself does not return any values. When an exception is thrown: does not even clean up the local variables. Do not understand, our rtti is not the use of the local object to do memory management of the destructor. ASSERT (S[s.size ()] = = 0); Works if is a const std::string, Butis undefined If it isn't const tried on VC2008, no problem.  Why would you say that, why? If You call Delete when you are should have called delete[], the pointer wilbe off by sizeof (int), leading to heap corruption and possibly code execution. Don't understand. If you call delete[] When you should have called Delete, some randomdestructors'll be called on garbage data, probably l Eading to code execution. Why, delete[] will compute several elements of the array, and the answer should be 1, there should be no problem-this may be related to the answer to the previous one.

From: http://www.cnblogs.com/baiyanhuang/archive/2011/05/20/2051704.html