Cross the road

When I was a child, adults always taught children to "cross the road and look around ". I don't know why when I was young, but because the adults were so Nagging Too many times that they were deeply imprinted in my mind, they became subconscious. Every time you cross the road, you can't help but look around. When I grow up, I gradually like to think about the problem. I always ask why: Why is it "crossing the road, watching around" instead of "crossing the road, watching on the left "? A friend told me that it is because of Chinese saying that the habits of the left and right sides, men and women, and old and young people are just like the habit of saying "Never give up" is not called "always a mother. However, I think the habit is developed. If I say "cross the road and look on the left" on a daily basis, I 'd say it's a habit ~
In fact, it makes sense to "cross the road, look around. All vehicles in China are on the right, so when crossing the road, the first half of the process (that is, the process from the beginning to the middle of the road) is always driving the vehicle from the left, the second half of the process (from the middle of the road to the right of the road) is always the vehicle from the right to the left.

As a saying goes, let's look at the left and the right. We can even say that we can only look at the left and the right when we leave the first half. If you turn your words in turn, you will be useless. Without this tactic, you may shake your head like a wave drum when crossing the road. (Note 1 ).
The Chinese do things very well to sum up a tactic, focus on the mind, the knife, the knife, the sword, and the sword, and even the book of the holy king wrote a book tips (I forgot how many tricks, ). Another example is that Sun Wukong burned his hair when he passed the Flame Mountain in Journey to the West, so he made a try on his left hand. This indicates that the phrase is very useful, and the skill is used by Sun dasheng: although you don't know how he came from, but it's right to follow the instructions-the old ancestor has already verified it Before summing it up.
In fact, there are a lot of tips during software development, even if you do not understand the truth, but follow the instructions, it is always correct. If you do not follow the instructions, you may have stabbed the hacker orCodeHidden risks that are hard to appear at the moment. The following is an example of the application in C .~)
For example, when a macro constant or macro formula is defined, parentheses must be added. Many people do not understand this, so they do not add it, the result is similar to the following:

# Define num_a 100 # define num_ B 25*2 # define int_div (a, B) a/bfloat C; C = int_div (num_ B, num_a); // The original intention is 50/100, the actual result is 25*2/100. The result is correct. c = int_div (num_a, num_ B); // the original intention of the author is 100/50. The actual result is 100/25*2. The result is incorrect. Imagine if we follow the rules: # define num_a (100) # define num_ B (25*2) # define int_div (A, B) () /(B ))
 

How can an error occur? For example, there is a saying: "Only declarations in the header file are not defined ". If you do not follow this rule, there will also be problems. For example:

 
// A. Hint max (int A, int B) {return A> B? A: B;} // main. C # include ". H "# include". H "// after two include operations, the max () is repeatedly defined, and an error is returned. Int main () {return 0 ;}
 

You may say that I add some material in. h to ensure that it is not defined repeatedly, for example:

 
// A. H # ifndef _ a_h _ # DEFINE _ a_h_int max (int A, int B) {return A> B? A: B ;}# endif // _ a_h _
 

Okey. Now the case above is done (note 2 ). But the following won't work:

// A. H # ifndef _ a_h _ # DEFINE _ a_h_int max (int A, int B) {return A> B? A: B;} # endif/_ a_h _/B. h # ifndef _ B _h _ # DEFINE _ B _h_void Foo (); # endif/_ B _h _/B. C # include ". H "Void Foo () {max (100,200);} // C. h # ifndef _ C_H _ # DEFINE _ c_h_void bar (); # endif/_ C_H _/C. C # include ". H "Void bar () {max (300,400);} // main. C # include "B. H "# include" C. H "int main () {Foo (); Bar (); Return 0 ;}
 

Separate compilation of B. C, C. C, and Main. C can also be done, but the last link is complete, because Max () is defined twice. So if the definition of max () is put in the. c file, and only the declaration of max () is written in A. H, this problem will not occur. (Note 3)
To sum up, what I want to say is: If you can fully understand the meaning of the phrase, it would be the best (to reach the realm of a sword in your mind, and to see the moves and moves, although every trick has no form, it implies a god of mouth.) If you cannot fully understand it, you may wish to follow the instructions first, instead of summing up the previous words and saying "Don't listen to the old man, ". After doing more, you will gradually understand the true meaning of your words and summarize the application scenarios, so as to avoid "Listening to the old man, the loss is at the end of the "realm! : P. Is this a negative? What I said. Pai_^

• Note 1: Later I thought: British cars are driven on the left, and whether they will teach children the formula:
  when going when SS the road, look right then left!: P
• NOTE 2: here we use the phrase "add guard macro in the header file", so this avoids a problem!: P
• Note 3: We can add an inline to the function defined in. h. This example is not good. I just think that the concepts of Function Definition and declaration are easier to describe than the concepts of variable definition and declaration. In fact, the error of writing "function definitions in. H" is rare. However, writing array definitions and initialization in. H files is common and sometimes a headache.