** 這篇的程式沒有實際編譯執行過，不保證沒有錯誤 **

很多時候我們得在 C++ 使用 C 語言寫的函式庫，
這時候 std::string 有幾種不同的方法來轉為 char*：

最安全也最常見的用法，是呼叫 std::string.c_str()。
這個函式會回傳一個標準的 char array，但是是唯讀的。

如果我們要讓 char array 可以寫入呢？
那就要先將字串複製到可寫入的 buffer：

變得麻煩了，對吧？

有沒有什麼方法可以直接更新到 string 而不用複製來複製去的呢？
std::string.data() 可以用來做這件事。
它回傳的是 string 內部用來儲存字串的記憶體區塊，所以修改值的話就會反應到 string 去。
不過舊的 C++ 標準並沒有強迫內部的記憶體區塊是連續的，所以這是有一點風險的。
另外，內部的記憶體也不保證會有 NULL 結尾，使用時一定要搭配長度的限制。

但風險也沒有那麼大，Herb Sutter 指出他目前所知的 std::string 實作，都是連續且 NULL 結尾的[1]。
所以用起來還算可以放心。

另外還有一個方式，就是使用陣列運算子。
因為 std::string[] 會回傳單一字元的參考，若對此參考取指標，就可以得到一個能用來修改內容的指標。
然而若對空字串取第一個字元 (empty_string[0]) 的話，不保證能夠得到 ‘\0’。
因此還是建議使用 std::string.data()。

在參考資料[2]裡面有很詳細的解說。基本上 C++11 解決了很多這類不確定的混亂情況，若是允許的話還是用新的標準編譯吧。

參考資料：
[1] http://herbsutter.com/2008/04/07/cringe-not-vectors-are-guaranteed-to-be-contiguous/
[2] http://stackoverflow.com/questions/347949/how-to-convert-a-stdstring-to-const-char-or-char

在 Beej’s Guide 看到這一句話：select() only works with socket descriptors, not file descriptors (like 0 for stdin)，想到我之前曾經把 tun/tap 的 file descriptor 丟進 select 裡面，不曉得我是不是做錯了。於是開始了一連串的搜尋，想要搞清楚 select 到底可以接受哪些 file descriptor…

大約花了快兩天的時間，我把相關的關鍵字都搜尋了一遍，然後把 man 2 select 與 man 2 select_tut 也看完了，接著跑去找出之前的程式，確認 tun/tap 並不是 socket descriptor 但是程式卻正常運作….

最後翻出手邊的 Linux 系統程式設計 這本書，把第二章重新看了一遍，發現書中直接就拿 STDIN_FILENO 丟進 select 來當範例。

嗯…難道是 Beej 亂寫嗎？
跑回去看那一篇文章，才發現他寫的是 Note for Windows Programmers 也就是說其實指的是 Winsock 的情況。

算了，反正看了那堆東西我還是有點收穫的，其中之一就是這個，如何判斷 fd 的種類：

參考：http://pubs.opengroup.org/onlinepubs/009695399/functions/fstat.html