Thoughts on Level 3 events caused by a type conversion

Thoughts on Level 3 events caused by a type conversion
A third-level event occurred some time ago. It turned out that it was an endless loop caused by overflow. It was a very risky event in the company, except that the boss had to deduct money, A reasonable explanation should also be given to the senior management. If you work in a small company, it may be okay even if the website goes down for a day. If you lose money every second in a large company, the loss that may be caused cannot be met even in Year 12, so the sense of responsibility and code consciousness are really important. Let's take a look at the problem code. Here I made a little modification. The code is very simple, that is, to get the number of binary 1 in the num parameter. Copy code 1 static void Run (long num) 2 {3 int I = 1; 4 5 long num2 = 0; 6 7 List <int> list = new List <int> (); 8 9 while (num2 = (long) Math. pow (2, I-1) <= num) 10 {11 if (num & num2)> 0) 12 {13 list. add (I); 14} 15 I ++; 16} 17} copy the Code. If this is the code you wrote, can you see the problem at a glance? We know that long is 8 bytes, that is, 64-bit binary, and because the highest bit in the binary is the symbol bit, when it is power 63 of 2, it displays the long minvalue, so when I = 64, the above Code is converted to long, so the final result is changed to long MinValue, if the data is recycled, it will go farther and farther on the negative number road. Then, this range overflow is not adopted by CLR, and OverflowException is not thrown to us, the tragedy is so heartless, the problem is, but can you think about it? In the strong conversion of primitive types, it is really suitable for using (long ), (int) is this strong conversion mode? In this example, we can see that this (long) mode does not detect overflow at all, so we 'd better not use this mode in the future, because in. there are too many strong transfer methods under the. net Framework. I know that there is no overflow detection, and some people may think that the conversion speed is the fastest, but how many people can swear that my program will never overflow, and I will be fully responsible for any behavior exceptions caused by program overflow? In order to promote the strong conversion of non (long), the following describes other strong conversion methods. I. To better understand the code, Let's first look at the original non-detection mode. 1 long I = long. maxValue; 2 int j = (int) I; In IL, we are delighted to see that this kind of strong conversion that does not detect overflow also has the proprietary IL command: conv. i4, which means to convert the value at the top of the computing stack to int32. Ii. checked: From the day we learned the C # language, we knew there was a checked. Its only role was to detect overflow. If yes, an exception is thrown. Let's look at the differences between this method and the Non-Detection Method in IL. 1 long I = long. maxValue; 2 3 checked4 {5 int j = (int) I; 6} Good Guy, it seems that a large string of code is actually an instruction in IL, in fact there is also an ovf, I think you should also be aware that there is an additional overflow detection during the conversion. If you refute the performance, it is true that the performance of this command must be slower than that without detection. What I want to do on the web is slow and acceptable. 3. Convet. ToXXX. This is the class C # used to encapsulate conversion operations for us. I strongly recommend this blog. Since it is recommended by me, it will certainly detect overflow, let's take a look at the code and IL. 1 long I = long. maxValue; 2 3 int j = Convert. toInt32 (I); on the IL, we can see that there are no special conversion commands, so the judgment must be in the Toint32 method. The following eyes will go to its source code to take a look. From the source code, we find that the original code is so concise, especially this if. if ToIntXXX is used at the time, the event may be intercepted in the test environment, maybe one day, this if is your last lifeline. 4: The IConvertible interface encapsulates many types of conversion methods in this interface, and all primitive types implement it, but it doesn't mean that Convert is called again. toXXX... 1 long I = 1; 2 3 int j = (IConvertible) I ). toInt32 (null); from the above IL, we can see that there is a box. It is no wonder that IConvertible is a reference type. How can it be left empty? This interface method is not worth mentioning in the case of value type conversion. it is not convenient to mention, and there is a large performance loss. Well, the summative words are also coming. ① No-check code mode: This mode is not recommended. It will kill you one day. ② Checked: Although there is a check, it is difficult to write. Of course, you can also set global detection in. ③ Convert. Toxxx: This article was written to advocate it, so I won't talk about the importance. It will save you one day. ④ IConvertible: in value-type scenarios, the performance is the worst and coding is not good.