一天一個C Run-Time Library 函數（緒）

繼續為windows/linux泛型服務器架構做研究工作，從C語言執行階段程式庫開始。

 

最好的可移植編程方式是什嗎？除了java。。。還有C。。。。，標準C是可以在幾乎任何有C語言編譯器的機器上啟動並執行，這是lua作者只用標準C開發lua的原因，並談到了lua可移植性好的理由。他說除了動態連結的模組，他用的幾乎都是標準C。

其實說起來移植性最好的可能是C++，C++的標準化工作在今天看來是非常成功的，C++的標準庫移植性也是非常的好，可是其實C++中大部分底層的操作還是靠C語言部分來完成，所以研究C++的庫好像也沒有意義，畢竟我的目的就是考察移植性而已，不是來考察庫的用法。。。

 

作為一個伺服器的架構，光用標準C好像有點難度。。。比如IOCP，epoll這些最好的伺服器模型都是典型的作業系統相關。但是，用C++語言編寫時，總會用到C語言的執行階段程式庫（在windows下叫CRT -- C Run-Time Library)。並且因為MS為C語言的庫做了很多擴充工作，並且將很多POSIX的東西標了前置的底線，並且都放在這個庫中，使得很多時候我自己都不知道哪些是標準庫的，哪些是MS擴充的了（都是常查MSDN不翻書的惡果，但是查MSDN的確快了很多）。今天又一次的碰到這個問題。

 

實際程式編寫的時候，使用這些庫函數，比使用windows API的可移植性（也許僅僅是移植的代價）要好的多。

因為沒有直接的類似資料可以查看，所以我下決心，直接一個一個通過實踐，決定哪個是windows/linux都可用的，哪些是新擴充，linux下不能用的。仿照很久以前看到某人寫的一天一個windows API來寫。我就一天一個C Run-Time Library的函數吧：）

 

呵呵，最近剛剛看完了一本bash的書，正好不想再學太多語言文法的東西，想好好的多編點東西，這個正好是個機會。另外。。。個人好像老是計劃的多。。。實際做下去的少，希望這個計劃能夠對自己的計劃能力做出考驗，然後做一個完整的PDF/CHM，方便大家，也方便自己以後的查看：）

 

另外還可以將MS那些前置的底線通過宏取消掉，最後還有一個非常非常有必要的事情也可以順面做了，那就是為linux下的庫建立一套asc/Unicode的自適應庫（類似TCHAR系統）。

 

順面，完整性，再貼一次我的開發及測試環境。

windows XP VS2005 VA vimemu boost 1.36

ubuntu 8.10 gcc version 4.2.4 vim+gdb boost 1.36

原始碼控制統一在windows XP 中用VSS.(個人習慣問題,公司用的就是這個)

另外:

其他工具包括.IBM Rational Rose Realtime(又是習慣問題,雖然不是Realtime的程式,但是因為公司用的是這個,個人沿用此習慣)