最近以提問的形式發了幾條關於編程思維的微博，有的獲得了粉絲的響應，有些卻無人問津。今天突然想到可以將我對這些問題的思考整理成一篇博文，以便與大家分享。另外，我計劃以“編程思維訓練”為名寫一些系列文章，希望通過這類文章與讀者分享我在編程活動中的一些思考。
問：有一對內存管理函數MemAlloc和MemFree，使用形式分別是：分配時為“void *p = MemAlloc (6)"，釋放時為“MemFree (&p)”。你能看出什麼問題嗎？有什麼建議？
答：一談到內存分配與釋放函數，我們很自然地會想到來自C庫的malloc和free函數。然而，MemFree與free在入參類型的定義上卻存在很大的差別，前者需要傳入的是指針的指針，而後者所需的卻是指針。由於MemFree函數的入參形式與free存在區別，這就容易造成使用者容易因為忽視這種區別而在初次使用時犯錯。
盡管MemFree的函數參數定義成指針的指針存在一定的好處 — 可以在MemFree函數中對所釋放內存的指針變量置NULL，但由於它違背了malloc/free的使用常識，因而不可取。我的建議是，定義API名稱時，應盡可能符合“常識”。
問：malloc與free是C庫中用於從堆中分配和釋放內存的函數。這兩個函數在命名上有什麼問題？如果給你重新命名的機會，你會如何做？
答：很顯然，malloc函數是“memory allocate”的簡寫，那相應的內存釋放函數應是“memory free”，如果采用一致的命名，free函數的名稱應是mfree。因此，C庫中的malloc/free函數存在命名一致性問題。
問：在Linux操作系統中，所有的外設都位於/dev目錄之下以文件的形式進行管理的，能否將socket也納入到/dev目錄之下呢？如果是你，你會如何做？為什麼要這樣做？
答：將外設放入/dev目錄，使得在Linux中操作外設或設備）與操作文件是相似的。這種設計一方面減少了API的數量，另一方面，使得程序員很容易掌握設備的操控編程。然而，Linux中的socket卻采用了完全不同的設計實現。
在Linux中如要打開一個socket，則必須調用socket函數，且在函數中指定是流類型stream），還是數據報類型datagram），以及所需打開的端口號。然而，從TCP/IP協議的角度來看，我們知道“流”對應的是TCP協議，而“數據報”對應的是UDP協議。這種映射關系盡管簡單但並不易懂），但不可避免的是，它仍然引入了“映射”這一行為復雜化了）。
如果將socket也按目錄的方式進行管理，那麼打開一個socket也可以用open函數，且目錄結構可以考慮采用協議名進行組織。比如，采用“open (“/net/ipv4/tcp/3344”, O_CREAT)”的形式打開一個端口號為3344的TCP socket，而采用“open (“/net/ipv4/udp/3344”, O_CREAT)”的形式打開一個UDP的socket。很顯然，這種方式並不需要引入“流”與“數據報”的概念，且簡少了API的數量。總體說來，基於目錄結構的socket設計將使得Linux在概念上更加一致。
實際上，目前的Linux中socket也是一種類型的fdfile descriptor），盡管造成目前的現狀有很多歷史原因，但它仍可以向前邁進一步。
本文出自 “至簡李雲” 博客，請務必保留此出處http://yunli.blog.51cto.com/831344/1031002
