Programming thinking training (1)

Recently, I posted several Weibo posts about programming thinking in the form of questions. Some of them received responses from fans, but some did not ask anyone. Today, I suddenly thought that I could organize my thoughts on these issues into a blog post to share with you. In addition, I plan to write a series of articles in the name of "programming thinking training", hoping to share some of my thoughts on programming activities with readers through such articles.

Q: There is a pair of memory management functions MemAlloc and MemFree, in the form of "void * p = MemAlloc (6)" at the time of allocation, and "MemFree (& p)" at the time of release )". Can you see the problem? What are the suggestions?
A:When talking about the memory allocation and release functions, we naturally think of the malloc and free functions from the C library. However, MemFree and free differ greatly in the definition of the input parameter type. The former requires the pointer to be passed in, while the latter requires the pointer. Because the input parameters of the MemFree function are different from those of free function, it is easy for users to make mistakes in their first use because of ignoring the difference.

Although MemFree function parameters define pointers as pointers, there are some benefits-you can set NULL for the released memory pointer variables in the MemFree function, however, it is not advisable because it violates the common sense of malloc/free. My suggestion is that the API name should be "Common Sense" as much as possible ".

Q: malloc and free are functions used in the C library to allocate and release memory from the heap. What are the problems with the names of these two functions? What would you do if you were given a chance to rename it?
A:Obviously, the malloc function is short for "memory allocate", and the corresponding memory release function should be "memory free". If consistent names are used, the free function name should be mfree. Therefore, the malloc/free function in the C Library has the naming consistency problem.

Q: In Linux, all peripherals are managed in the/dev directory in the form of files. Can socket be included in the/dev directory? What would you do if it was you? Why?
A:Put the peripherals in the/dev directory, so that the operation of peripherals or devices in Linux is similar to the operation file. On the one hand, this design reduces the number of APIS, and on the other hand, it makes it easy for programmers to master the control programming of devices. However, the socket in Linux uses a completely different design implementation.

If you want to open a socket in Linux, you must call the socket function. In the function, it must be a stream type), a datagram type datax), and the port number to be opened. However, from the perspective of TCP/IP protocol, we know that "stream" corresponds to TCP protocol, while "datagram" corresponds to UDP protocol. This ing is simple but not easy to understand), but it is inevitable that it still introduces the "ing" line to complicate ).

If you manage the socket by directory, you can use the open function to open a socket, and the directory structure can be organized by protocol name. For example, open a tcp socket with port 3344 In the form of "open ("/net/ipv4/TCP/3344 ", O_CREAT, however, a udp socket is opened in the form of "open ("/net/ipv4/UDP/3344 ", O_CREAT. Obviously, this method does not need to introduce the concepts of "stream" and "datagram", and reduces the number of APIs. In general, the directory-based socket design will make Linux more consistent in concept.

In fact, the current Linux socket is also a type of fdfile descriptor), although there are many historical reasons for the current situation, it can still take a step forward. 650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/16410Q541-0.jpg "border =" 0 "alt =" "style =" border: none; padding: 0px; margin: 0px; vertical-align: top "/>

This article from "to Jane Li cloud" blog, please be sure to keep this source http://yunli.blog.51cto.com/831344/1031002