Artinna-Lau
string和char是不一樣的。char我們更瞭解他們內存地址。無論是指針還是數組都很瞭解。對於底層代碼用char。邏輯代碼用string。我是這麼使用的，
罄竹10
在C++中優先使用String是一個良好的習慣。除非是C的死忠者習慣如此，否則應該使用String而不是char。
char是用來處理任何8bit數據類型的，邏輯值、整數、字符ASCII碼等都可以。要用來處理字符串需要使用char[]數組，比較麻煩，也不好控制。
String是一個模板類，它是專門用來處理字符串的，封裝了很多處理字符串的成員函數。並且它是C++標準庫的一部分，是所有C++實現都支持的，也是C++創始人推薦使用的。
術業有專攻，應該用哪一個不難選擇吧。
Assault53484432
string 是C++ std裡的模板類。 不是MFC 的CString類。C語言根本沒有類的概念。
使用string 最大問題是需要運行時庫，所以無法運行在無vc++201x的電腦上。CString 與char *都不會出現這種情況。
CString 比string更好用。所以如果你編寫MFC程序最好用CString類。
如果使用結構體，必須使用char[],不能用類。特別是網絡封包程序。
考慮到程序能在所有電腦運行，不需要額外安裝運行庫的情況下，只能強制使用char*
輕風扶醉
作為一名一線開發者，下面說說自己的看法。如有不同意見，歡迎留言討論。
先說下自己的觀點，個人不是很看好你們領導這種，堅持用char而不用string。
既然選擇了C++，那麼為什麼不用STL早已為我們封裝好的string呢？
string其實現就是一個帶有長度的char * ，幫我們省去了自動管理內存的麻煩，都已經0202年了，你還會擔心內存不夠用嗎？
個人猜想：
也許你的領導在某一項目中使用了string過程中被深深的坑了一把，但是卻不知道具體原因，所以立下了祖訓：禁止使用string！
也許在調用某個廠商提供的動態庫時，在接口中使用了std::string而不是char * ，結果遇到了靈異事件，程序莫名的崩潰了，連自己的調試器都沒有進入，至此，禁止使用string 這一莫名的結論就一直流傳下來了。
那麼如果我們真的遇到某些廠商的SDK出現這種奇葩庫，怎麼破？
答案很簡單：用發佈那個dll的VC版本，再寫個動態庫做封裝庫，把接口轉發成char*。
一個程序員的奮鬥史
string曾經使用COW優化，變成一個有時是值語義有時是引用語義的怪物。而且當使用引用計數時，早期的有些版本居然沒負責線程的競態條件，因此線程不安全了。早期的版本，小長度的字符串也使用堆內存，是性能的大漏勺。string是技術發展的熱點，新技術的試驗場，因此實現五花八門，不能用來做DLL。C+++20出現後，string應該以SSO技術為主流了，小長度字符串不會觸發malloc操作。再配合string_view,也是很高效的。總之，2020年代，用string還是不錯的選擇。
Thomas76
C陷阱與缺陷還是程序員的自我修養裡面講過，char*不會被內存緩存，存儲隱私數據時要用char*，用string可能會導致隱私數據洩露
貓呢個咪的
看環境和問題，char 和string 有不同的應用場景。不說明情況，誰知道怎麼回事？總的來說，最大的可能是你懶不願意考慮到底要用char（？）幾，所有的都用了string，所以領導才強制你用char。另外，數據庫定義字段也有char的長度限制，你不過腦都用string等著爆bug吧。真實情況一般都是char用的多也穩定，少部分情況用string。
懶爸爸育兒日記
那就用char[]嘛，然後再封裝一下，用起來來和string一樣方便。
視頻音頻通信呼叫中心
你領導說的是對外接口用char不用string，你自己理解偏差吧
hxh0791
在嵌入式上，char一定好用，string就不一定了。
C在開發效率上的確不去C++，但是至今沒被淘汰，自然有其獨特的優勢。
你可以問問這個前輩，很有可能他會告訴你，這樣寫是為了可移植性。他可能並非不會用string
