Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what are the traps of CAccord + returning internal static members". In daily operation, I believe many people have doubts about the trap of returning internal static members. Xiaobian consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the questions of "what are the traps of CAccord + returning internal static members"! Next, please follow the editor to study!

There is always a problem that will upset us in the process of developing with CumberCraft +. The problem is that in-function and out-of-function code needs to interact through a block of memory (for example, the function returns a string), which bothers many developers. If your memory is allocated on the function stack, the memory will be released by the stack as the function returns, so be sure to return a piece of memory that is still valid outside the function.

This is a problem that bothers countless people. If you are not careful, you are likely to make mistakes on this. Of course, there are many solutions, and if you are familiar with some standard libraries, you can see a variety of solutions. Generally speaking, there are the following:

1) allocate memory on the heap through malloc or new inside the function, and then return this memory (because the memory allocated on the heap is globally visible). The problem caused by this is the potential memory problem.

Because, if the returned memory is not freed, it is memory Leak. Or it is released multiple times, resulting in the crash of the program. Both of these problems are quite serious, so this design method is not recommended. (in some Windows API, when you call some API, you must also call some of his API to free this memory.)

2) ask the user to pass in a piece of his own memory address, and put the memory to be returned into this memory in the function. This is a commonly used method at present. Many Windows API functions or standard C functions require you to pass in a buffer and the length of the buffer. This way should be common to us. The advantage of this approach is that the memory is maintained by programs outside the function, which is relatively simple and intuitive. But the problem is that there is a little trouble in using it. But this approach reduces the chances of making mistakes to *.

3) the third way seems to be more alternative, it takes advantage of the characteristics of static, once the stack memory of static is allocated, then this piece of memory will not be released with the return of the function, and it is globally visible (as long as you have the address of this memory). Therefore, there are some functions that use this feature of static, that is, there is no need to use memory on the heap, and there is no need for the user to pass in a buffer and its length. As a result, the function you use is beautiful and easy to use.

Here, I would like to discuss the third method. Using static memory may seem like a good idea, but it has pitfalls you can't imagine. Let's give an example of what actually happened.

Example

Anyone with experience in socket programming must know a function called inet_ntoa. The main function of this function is to convert a numeric IP address into a string. This function is defined like this (note its return value):

Char * inet_ntoa (struct in_addr in)

Obviously, this function does not allocate memory on the heap, and it does not ask you to pass in the buffer of the string, so it must use the "return static char []" method. Before we continue our discussion, let's take a look at the knowledge related to the IP address. Here are the arguments that the inet_ntoa function needs to pass in: (you may wonder why only a struct of member should be put in the struct? This should be for the sake of future extensibility of the program)

Struct in_addr {unsigned long int slots addr;}

For IPV4, an IP address consists of four 8-bit bit, which is placed in the s_addr, followed by the high order, which is to facilitate network transmission. If you get an integer value of s_addr: 3776385196. So, open your Windows calculator and see what its binary is? Let's make a group of 8 bits from right to left (shown below).

11100001 00010111 00010000 10101100

Then convert each group to decimal, and we get: 22523 16172, so the IP address is 172.16.23.225.

All right, let's get down to business. We have a program that wants to record the source and destination addresses of network packets, so we have the following code:

Struct in_addr src, des;. . Fprintf (fp, "source IP address\ t destination IP address\ n", inet_ntoa (src), inet_ntoa (des))

What will happen? You will find that the source IP address and destination IP address recorded in the file are exactly the same. What's the problem? So you start debugging your program, and you find that src.s_addr and des.s_addr are not the same at all (see below). But why is the source and destination of the output to the file the same? Is it inet_ntoa 's bug?

Src.s_addr = 3776385196; / / corresponding to 172.16.23.225 des.s_addr = 1678184620; / / corresponding to 172.16.7.100

The reason is that inet_ntoa () "cleverly" returned the internal static char [], and our program stepped into this trap. Let's analyze the fprintf code. When we fprintf, the compiler first evaluates inet_ntoa (des), so it returns the address of a string, and then the program asks for the inet_ntoa (src) expression and gets the address of a string.

The address of both strings is the static char [] in inet_ntoa (), obviously the same address, and the second time you ask for the IP of src, the IP address content of the des of this value must be overridden by the IP of src. So, the string memory of both expressions is the same, and at this point, the program calls fprintf to output the two strings (actually one) to a file. So it's not surprising to get the same result.

Taking a closer look at inet_ntoa 's man, we can see this sentence: The string is returned in a statically allocated buffer, which subsequent calls will overwrite. Confirms our analysis.

This is the end of the study on "what are the traps for CramCraft + returning internal static members". I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.