為什麼儘管 C++ 早就有了很多現代功能，但是卻長期給人原始的印象呢？

01-11

以前（特別是 C++11 之前），很多人提到 C++ 就想到 C，就想到手工管理內存，就想到標準庫弱。但其實很多現代功能早就有了（Boost），比如 regex 是 boost 1.18 的功能，不晚於 2003 年，smart pointer 是 1.23，同樣不晚於 2003 年。這基本就是 C++ 鼎盛的時期。
可是為什麼之後 C++ 卻開始走下坡路，而且（在中國）給人以危險、原始、難用的印象呢？

題主的問題是針對 C++ 本身的特性。但題主給出的數據提到了 C++ 盛衰的時間點。這個盛衰和行業需求的關係更大，而非 C++ 本身的特性。

2003 年以前，個人計算機的一大部分需求是 content creation。比如文字排版、圖像製作。這個需求在 03 年之後的比例逐漸降低。並不是說絕對需求降低，而是隨著用戶基數的增加，相對比例下降。大部分新增用戶的需求轉向信息的整合共享。這前後的區別在於，content creation 的工具需要和 OS/hardware 更強的互操作，而信息整合共享往往需要一個能更好的處理 on-wire protocol 和字元串的語言就夠了。

另外隨著網路的發展，各種利用簡單拼裝的技術開始發展起來。比如說想在 app 里加一個地圖，03 年之前大概就要自己實現或者用 OS 的 UI 功能去集成一個 native 模塊。而後來用 Google Maps 做一下網頁的 marshup 就行了。

C++ 應該說是在這些因素下由勝轉衰的。但是在遊戲和工具領域仍然是主流。

這個問題有意思。我之前也想過。

個人認為這是心理問題。

各行各業很多人(更別說那些不喜歡用c++的)都喜歡用所謂的官方、自帶，並對其信任，有敬畏之心。

如果需要第三方，則絕對麻煩和質疑。

且恰恰C++本身更多的就只是語言，而不是庫。

---------------------------------------

我發現也因為有很多人不知道（Linux下）如果讓高版本編譯器編譯的程序如何跑在低版本機器上……哎

因為當新標準出來以後，總會有（友善度）（友善度）大喊：

「C++越來越複雜啦！」

「C++越來越難學啦！」

「搞那麼複雜，遲早會退出歷史舞台！！」

「出這個新標準有什麼用，我舊的還都沒學好！」

「c++程序員的悲哀！」

「大量使用這種語法的後果，就是調試成為一場噩夢。」

「增加了複雜性！誰知道編譯器後邊做了什麼工作呢？在這樣發展下去的話，估計沒有幾個人會用了，簡單才是硬道理！unix推崇簡潔！應該向它學習！」

當這樣的人占的比率越來越大的時候，c++的標準不論怎麼改，它永遠都是一門落後的語言。對很多人來說，他們的編譯器版本永遠的被智子鎖死在了VC++6.0

只說點個人經驗/吐槽，不具普適代表性。

新C++規範是讓這門語言越來越便利了，特別是開發上層應用的時候（以及為這些上層應用開發某些底層庫的時候。

而開發上層應用的空間現在有許多語言可以選擇。有Java和C#這倆主流的託管語言，以及Python / Ruby / JavaScript這些以前偏向腳本場景的語言，近來新的Go和Swift也不錯。Rust雖然也上可攻應用下可守底層，但還是應用在偏向底層（系統編程）更多些。

這些新語言大多選擇不與C語法兼容，扔掉了C++的歷史包袱，做得更乾淨而現代。新C++寫應用也可以很現代很順手，但有這麼多選擇的情況下，是否要選擇（新）C++就有許多因素要影響了。例如說能否招到大量熟練能幹活的碼農——許多公司都是因此而選擇了（大家鄙視的）Java，碼農好招啊。

回到底層，確實新C++有許多有趣的功能（特別是語言層面的改進，例如rvalue reference和move semantics）在底層也用著很順手，用來實現庫給上層應用使用很方便。但是在某些特定的底層領域，新C++其它的一些新功能根本沒法用。

例如說我們寫帶GC與JIT的VM時，我們需要用C++來實現GC以及對象系統自身，而這種能在C++層面以下移動對象的行為用新C++就不方便表達，最後還是基本上用會很原始的C++子集來實現功能。

有不少現在算是主流的帶GC與JIT的VM實現都是只用了很小的C++子集，大致可以看作C with Classes + simple templates。

造成這個狀況有許多原因。

當然一個很重要的是不少此類項目的歷史都比較久了，它們開始寫的時候C++都還沒很好的規範（連C++98都還沒），所以當時沒辦法用高級功能，而後來歷史一久代碼就很難演進去用新的C++功能。例如CLR、HotSpot VM。
也有一些原本是用C寫的，後來才轉換為使用C++，例如SpiderMonkey、Dalvik VM等。這些項目不免還延續著一些C的習慣。
但無法忽視的一個原因是：這些實現通常需要非常非常精確的底層操作，而新C++的許多功能要麼靜態類型限制太強而動態功能不足，要麼太過於高層難以精確控制，很難在這種項目中使用。

這裡，

「帶GC」是偏向可以移動對象的GC（如基於mark-compact或者copying的），而不是只用引用計數或保守式mark-sweep的GC。因而需要精確控制對象布局以及不能依賴C++的非POD類型的功能，而只能用POD類型。
而「帶JIT編譯器」主要強調可以動態生成代碼與VM里的數據交互，因而同樣要能精確控制對象布局（以及其它一些可變長度數據結構的布局，或者是例如說一些flags里的bit的布局等）。

引用Slava大大的一條推：

https://twitter.com/mraleph/status/686196236530114564

Vyacheslav Egorov (?@mraleph)
with the way C++ standard and compilers are going people writing VMs would be soon forced to start by writing a language to write a VM in

（Slava大大是V8和Dart VM的研發工程師。「Slava」是Vyacheslav的昵稱。）

之前我練手試過儘可能使用C++11的功能來實現一個JavaScript runtime。但很多時候這些新功能都幫不上忙，其實還是在用新流行的C++代碼風格搭配老C++的功能來寫。

假如要寫個discriminated union來表示「值」，例如：

#include &


enum class MyValueKind {

  Number,

  Boolean,

  String,

  Object,

  Undefined

};
class MyObject;
struct MyValue {

  MyValueKind kind_;

  union {

    double         n_;

    bool           b_;

    std::u16string s_;

    MyObject*      o_;

  } val_;
  MyValue(double n): kind_(MyValueKind::Number) {

    val_.n_ = n;

  }
  MyValue(bool b): kind_(MyValueKind::Boolean) {

    val_.b_ = b;

  }
  MyValue(std::u16string s): kind_(MyValueKind::String) {

    val_.s_ = s;

  }

MyValue(MyObject* o) : kind_(MyValueKind::Object) { val_.o_ = o; } };

這段代碼就編譯不過，因為std::u16string有non-trivial constructor，導致val_的那個匿名union不能成立。

到最後這MyValue類型還是得人肉寫，而且不能用std::u16string放字元串類型的內容。

當然有Boost.Variant這種東西，但不能精確控制內存布局的話這裡就會對其它東西的實現有影響，所以也沒辦法用。

（當然咯，實際實現這MyValue要想高效也不會用這種discriminated union，而會用例如NaN-boxing之類的，也是要人肉寫些「有趣」的包裝。

看幾個JavaScript引擎的value representation：

用NaN-boxing的JavaScriptCore：webkit/JSCJSValue.h at master · WebKit/webkit · GitHub

用Nun-boxing的SpiderMonkey：http://hg.mozilla.org/mozilla-central/file/tip/js/public/Value.h

用tagged pointer的V8：v8/objects.h at master · v8/v8 · GitHub）

上面的例子還只是「值」的表現方式，到對象的表現MyObject就更麻煩了。

假定這是一個由GC管理的類型，而我們想要實現一個Copying GC——需要移動對象的話，通常都是用raw memory copy的。但C++里非POD-type不能用std::memmove()來移動，而此處又不適合調用對象的拷貝構造函數來移動對象。因為GC是通用的而對象系統是可擴展的，要在運行時調用合適的拷貝構造函數就得知道其準確的C++類型，但GC在移動一個對象時既無法靜態知道其準確類型（所以無法使用新C++的增強的靜態類型系統），也不便於動態的找出其拷貝構造函數（C++的RTTI功能太弱）。

於是這MyObject也得實現成POD類型，並且用些奇技淫巧或者是依賴於C++編譯器實現的行為（而不是由C++標準保證的行為）來實現。

看看那些用C++實現的帶GC與JIT的VM，它們的對象模型部分，是不是都很不「新C++」？這都是有苦說不出啊。

看看Android ART所實現的Java對象模型。它已經算是用了比較新的C++了，看起來很現代，但跟用C++寫更高層的應用相比還是顯得「原始」：https://android.googlesource.com/platform/art/+/master/runtime/mirror/object.h

先說小規模用戶。別的語言基本是集公司，官網，官方實現，官方repo，官方packge manager，官方distribution於一體的，用戶體驗一致，能快速吸引新用戶，標準庫更是加加加（battery included）。

而C++標準委員會則感覺是一群人各自代表己方的利益，又不希望把語言弄成所有需求的並集（所謂設計要正交），進展就非常慢吞吞了。小規模用戶不喜造輪子，而「官方」造得太慢，質量也有爭議，所以慢慢地（ms一波推熱潮結束之後）也就沒人關注了。

大公司的話，我比較了解Google。Google一直在內部推C++11，但是對每個新特性都極其慎重地考量。允許了的特性確實都在內部廣泛使用；新手問問題能及時得到答案；各式各樣的輪子遍地都有，很少需要自己發明。

結論是要流行就要有高質量社區推，或稱marketing - 畢竟喜歡自學或是喜歡造輪子的人是少數呢。如果不流行了，哪怕之後突飛猛進，知道的人自然不多了。

至少對我來說，不覺得原始。而你說到的這些現象是因為，人的惰性，好比現在老一代的人，不會使用ATM，每次去取取錢都在櫃檯排長隊，即耗時又麻煩，每次還抱怨，但就是不願嘗試ATM機。問他為啥，回答就是不會，讓他學，回答就成了那個不安全。

這現象也同樣發生在C++方面，Bjarne Stroustrup也表達過類似的意思，他說人們如果能通過老舊的手段完成工作，他們會停止嘗試新的方法。

那麼問題來了，人們會覺得C++因為兼容C而留下種種"歷史包袱"，那他們會覺得C原始嗎？然後你會發現大部分吐槽C++的人都是半罐水響叮噹的，C++不是僅僅一個處理業務的語言，它還是能做架構設計的語言，至少在語言這一級提供了足夠多的概念。所以只會有極少的，想吐槽C++的人他們並沒有在吐槽，而是選擇改進C++。

在中國給人一種原始難用的印象，只能怪老師咯，怪一些所謂的大牛咯。你看到的那個圖表只是一個市場的反應，每年中國給世界輸出了這麼多碼農，C++只是長得慢一點而已，因為增速被拉開了。如果有人通過此圖選擇最火的編程語言來學習，那在一個相當長的時期內，他的工資很有可能都不會太高。

一個先天有缺陷的設計是無法通過小的修修補補變成偉大設計的。

這是 Eric S Raymond 在 TAOUP 一書裡面所說。

我的觀點是，C++ 從科學角度看起來很美好，從工程角度它不如其他語言好用。如果編程的主力軍是軟體工程師而非軟體科學家，那麼 C++ 的衰落是必然的。C++ 的缺陷就在於低估了人類本身的缺陷。

往大了說就是C++已經過了巔峰期。新的標準就像Fortran 90 --- 這個語言在努力跟上時代，但是使用者的平均年齡在變大，項目都巨大且有年頭了，新項目越來越少了。

這樣的社區自然越來越難以接納新東西。

另一方面，C++的語言機制大都是leaky abstraction，範例看起來很漂亮，實際使用有很多坑，非熟悉其實現細節不能運用。典型如STL用起來看似簡單，但等閑生成幾屏幕錯誤信息，包含各種你未曾聽說過的內部名字。

這極大阻礙了C++庫的推廣。C和Java都沒有這個問題。像Spring Framework這樣魔幻的庫能被普及，對於C++是不可想像的。

再者，C++大概是貫徹「絕不直接給用戶他想要的」最徹底的語言。現代語言要有好用的string, array和dict？我們絕不給核心語言加這些類型，而是加入各種機制，使得用戶自己可以實現別的語言中內置類型的效果。（我們甚至允許你自定義字元串字面量！）

這既拖慢了C++在上升期的發展速度（我們到哪年才可以用字面量初始化map的？），也加重了上一個問題（想想錯誤信息里那些冗長的basic_string）。

再回到原問題。原不原始的先不論，C/C++作為不安全的語言，不管加入多少特性，始終還是危險和難用的。只是很多領域，暫時沒有/沒有流行更好的選擇。

（考完試來答一發）從一個計算機專業本科生的角度說一點自己關於C++這門語言和關於編程的本科教育的一點想法吧。

個人經歷：2010年開始接觸C++、NOIP一等獎，上大學後就讀計算機系，目前大三。

-------------------------------------------------------------------------------------------------------------------------------------------

樓上幾位答主都已是專業的程序員、工程師，是從工業界使用的角度看C++。但是至少就目前的我而言，C++更多的是一門教學語言和工具語言。

首先，C++ （在中國）給人以危險、原始、難用的印象，我認為是從教育開始的（抱歉關於C++走下坡路的這段歷史我不太清楚，那時候我還不知道C++是什麼。。。）。

當大一新生進入大學，首先要學習什麼叫編程。語言作為一個載體，自然就要承擔著啟蒙工具的作用。目前大多數學校還在用C語言作為入門語言吧。C語言是否適合入門暫且不提，以目前編程在初高中的普及度來說，它對於大多數新生是something magic。而且C語言本身是很接近底層的，又有指針這種見面殺的難點，已經給人留下了C語言難用和危險的印象了吧。

（等等我們不是再說C++嗎，為什麼說C語言。）

接下來，入門結束，繼續學習到了C++。這個名字說實話起的太有誤導性。我是傾向於認為C和C++是兩門不同的語言的，不存在誰是誰的」擴展「（但是C++的編譯器可以兼容C）。於是原本應該由C來背的鍋，很大程度上會被帶入到C++來。而且，這個階段的課程對於C++的高級特性往往也不會深入探討，最深也就是講到多態、繼承，並希望以此為學生打開面向對象的大門。結果是不知道多少人只是把C++用成了C with class，再好一點是C with STL。換句話說，停留在C++99的時代止步不前。

甚至，某些學校的非計算機系的編程課程，還在用著C89時代的語法，用著VC6.0教學生編程。這真的能做到普及的作用嗎。這種方式無疑是讓更多沒有意願也沒有精力對編程做更多了解的同學再一次加深」編程真難「，」C語言好痛苦「這種印象。

原始就不用提了，C++11、C++14標準遲遲不被寫入教材，不關注語言的同學們（對，是半數，甚至以上）會去關心C++有沒有實現lambda表達式嗎，會去關心C++有沒有實現類型推導嗎，更不要提其他的從語法上感受不到的特性了。它」原始「，是因為學生學習到的就是原始的。

-------------------------------------------------------------------------------------------------------------------------------------------

其次，關於C++的普及。C++真的不是一個善於表現自己的語言，或者說不討人喜歡。就說debug，除了VS能夠提供稍微強一點的調試環境和錯誤提醒，其他的IDE真的很難用。上個假期接觸到了C#，它的開發過程甚至可以用享受來形容，它給我了完全不同的編程體驗（當然也是因為我接觸的不深還沒有看到C#的醜陋的一面，我也並不認為C#比C++更適於入門，更不認為C++難於調試是這門語言的鍋）。

C++的學習成本也真的很高。他有著不小的歷史包袱，也經歷過高級特性與底層自由度的糾結。想要精通C++，如上面一位答主說的，十年也不一定夠。至少對於STL，我通讀了一本The c++ standard library: a tutorial and reference，也不敢說應用自如。

-------------------------------------------------------------------------------------------------------------------------------------------

總結，可能我說的這些只是不會影響題主那張曲線圖的微小的因素，但是真實地發生在我身邊每一位同學（大神請繞路）身上。希望C++能夠被重新認識，希望計算機系的本科教學設置更為合理，希望每一個立志於計算機科學的同學能夠得償所願。

一、許多人總偏愛語言自帶的庫。

二、許多人對C++的理解一直停留在差不多二十年前的標準。

感覺這兩個是主要原因，其他的更深層次確實是C++缺點的原因並不是大部分人認為C++落後的原因。

那些是boost有，不是C++有。不是每個人在那個時代都能接受編譯和使用一個巨大的庫。

早年C++之所以流行，是因為只有這一種語言是在幾乎任何領域內都適合使用的......

現在儘管C++早就有了很多現代功能，然而在各個領域中，基本上都出現了在本領域內比C++更加現代的語言......

所以，在大多數領域中，C++還是給人一種原始的印象......

反對 @韋易笑

堅持不刪除/調整舊特性

刪除的特性：export、std::auto_ptr等等；

調整的特性：auto、class/typename、幾乎所有的類庫。

把這兩條放一起，明白人都能知道，這一個是矛一個是盾，長此堅持這兩條原則走下去，語法只會越來越晦澀，冗長，詭異，失去優雅，並最終陷入兼容性地獄。
反向思考下就能明白，增加特性帶來便利的另一面其實是帶來了一種束縛。

這種有強烈主觀傾向的見解本是不太好反駁的，不過韋老師經常安利的C和Java似乎完美地適用以上評論啊。

/********************************/

韋老師修改了答案，這裡也補充回應一下：

堅持不刪除/調整舊特性（指範式和特性級別的刪除不是邊角廢料的刪除）

所以BS和HS才在推isocpp/CppCoreGuidelines · GitHub

另外「特性級別」是什麼鬼？

「不是邊角廢料的刪除」，不是邊角廢料的都是有用的東西，有用的東西刪了是想幹嘛

/********************************/

繼續回應 @韋易笑

你也被標準委員會還有社區忽悠了，你發的幾篇編程指引動不動就是充滿modern c++，complete new language，這些詞眼，以為加了幾個新特性，再配合這些刺激的語句以後c++就真的和以前沒關係了，他們之所以這樣基於切割就是變相承認老問題，並且面對大眾對經典c++的各種指責乏力回應，就像文革時期爹被抓了，兒子怕引火上身急於撇清關係一樣，然而除非c++放棄諸如c兼容徹底接管內存語言級蛻變，做一個高級語言；或者放棄諸如模版或者exception/隱式構造一類的特性，俺守本分做一個系統級的better c，否則拋開這些不談，僅憑几個新辭彙就開始叫囂完全是一門新語言，這本來就是標準制定者門在給你們洗腦呢，你們還真信了，就跟日本學者和軍國主義天天在喊脫亞論一般，說的多了，有些不明真相的日本群眾還真相信了。

下面切開來逐條回復：

你也被標準委員會還有社區忽悠了，你發的幾篇編程指引動不動就是充滿modern c++，complete new language，這些詞眼，以為加了幾個新特性，再配合這些刺激的語句以後c++就真的和以前沒關係了，他們之所以這樣基於切割就是變相承認老問題，並且面對大眾對經典c++的各種指責乏力回應，就像文革時期爹被抓了，兒子怕引火上身急於撇清關係一樣

必須承認C++確實一直急於和C「撇清關係」，但是標準委員會從來沒有以為現在的努力已經達到了目標，我也多次聲明要想徹底排除C++的遺毒必須重新設計語言。至於「變相承認老問題」，據我的認知承認老問題一向承認得很直接吧。至於文革的例子，從道理上什麼也說明不了。

然而除非c++放棄諸如c兼容徹底接管內存語言級蛻變，做一個高級語言；或者放棄諸如模版或者exception/隱式構造一類的特性，俺守本分做一個系統級的better c

拋棄C兼容我同意，徹底接管內存我不同意。C++比起C的優勢在於，既提供了對資源精確控制的可能，又提供了對資源管理強大的抽象能力。你要說矛盾也好，你要說抽象漏洞也行。事實是別的語言的做法概括起來就是：要麼像C一樣抽象能力低下，提高開發維護難度的同時，又沒有明顯的性能優勢；要麼像Java一樣把所有的case性能水平拉低到同一個級別，缺少workaround的餘地。

放棄模板和exception也不敢苟同。對於模板，首先你得先證明STL與boost的模板庫的無用，或證明其使用非模板的可替代性。對於異常，首先你得說出RAII + 異常的缺點，或證明其可替代性。

減少隱式構造這一點我同意，這貨就是C的隱式轉換和C++設計哲學相結合搞出來的爛東西，例如：

// C代碼： void func(double); // 調用姿勢可以是： func("c");

C++設計的一個原則就是用戶的自定義類型的行為儘可能與內建類型保持一致以達到最小驚訝，可惜的是C的設計最初就沒有考慮內建類型的最小驚訝，導致C++就出現了很多莫名其妙的隱式構造。這一點除非設計新語言，應該很難有比較大的改觀。

但是無論如何做一個better c是一個很糟糕的建議，說C++爛很大程度上就是因為大量的基礎語核抄自C，倒不是全是因為C設計不好，其中相當一部分是因為C的設計哲學和C++不符。

否則拋開這些不談，僅憑几個新辭彙就開始叫囂完全是一門新語言，這本來就是標準制定者門在給你們洗腦呢，你們還真信了，就跟日本學者和軍國主義天天在喊脫亞論一般，說的多了，有些不明真相的日本群眾還真相信了。

我們所說的新語言一直是語言級別兼容，但是所有最佳實踐的編程範式都不是C風格的。所以說，如果你想享受C++帶來的便捷與高效，請不要用C的風格寫C++。"帶類C"一黨不少人邏輯真的很流氓：聲稱只用C++的類和兼容C部分是最佳的C++使用方式，然後在實踐中踩坑無數，儘管這其中大多數坑都是C風格範式帶來的坑，他們還是喜歡把罪算到C++頭上。要是怪的是C++兼容C之罪倒還有點道理，可他們最喜歡怪罪的是他們從來沒有認真用過，也從來沒有坑過他們的特性。

事實上，Modern C++和以前的C++或是C是否是一個語言，或者有多少共通根本不重要，重要的是現在的C++比以前更好用了。

c++14已經非常好了,

很多人沒用(沒學習),或者還停留在98的時代.

c++17過後一定會更好!!!

讓我們拭目以待吧!

回復嚴雲:

資料在這:cppreference.com.

不要看其他的,只研究這個,就夠了.

為什麼危險難用？我覺得我國的很多C++程序員，都跟美國人一樣over confidence，天天在想「我覺得這件事情就得這麼做，儘管跟Bjarne Stroustrup說的不一樣」。然後做砸了，也不檢討一下自己，然後就開始罵C++，然後要麼轉C，要麼轉go，轉別的，然後就開始膜拜這些語言的爹了，說什麼都是對的。

太極端了

因為不原始的那一部分費腦子

如何在W8.1的系統里使用TurboC2.0? - 生活

為什麼國內的一些一流大學還在用Turbo C教C語言？ - 編程

為什麼TC2.0與GCC的整型變數長度不一樣?難道變數長度沒有統一標準? - C（編程語言）

c++03開發程序有多噁心你是不知道。。。

沒有auto經常typedef到想死，改名字要改一大片

沒有lambda每用一次algoirthm要定義一個struct，algorithm你真的有存在意義么？

沒有move只能天天swap

沒有pefect forwarding模板函數overload到眼花

沒有variadic template模板加宏寫到吐

c++03噁心人的地方太多了，不一一舉例了，暴死活該

c++11才是真的c++

說一點不成熟的看法：

感覺是因為那時候各種輪子確實已經足夠多了，然後寬頻興起，大家猛然發現寫業務才是賺錢的王道，於是低端碼農紛紛投身寫業務去了，比如我。然後大神們依然在孜孜不倦地造輪子，並且不停地出書告訴大家如何才能更好的造輪子。

然後對於絕大多數C++新手來說，不但學C++的時候像在聞屎，工作中又很容易把業務寫成屎，又不肯花時間努力提升自己避免寫成屎，所以C++的圈子就是現在這個屎樣子。圈內的自high，圈外的只要每天for for for if if if return return return 業務就寫完了。等C++11搞了10多年，終於讓C++學起來屎味沒那麼重的時候，機會早就屬於其他語言了。

我現在還在用C++寫業務……碰到UI直接CLI + WPF……

應該這麼說，c++ 就沒打算現代過。或者更準確的說，我們今天對現代的普遍定義：「簡明、安全和開發效率高」，並不是 c++ 設計者和使用者的訴求。

c++ 的兩個核心設計原則：

C Compatibility
Zero Cost Abstraction

第一條註定 c++ 會繼承 c 幾乎全部的語法和語意，而 c 必須直面手工內存管理這些事。

第二條就更難了，大家可以試試自己寫個 string 類，無論什麼語言，讓它既像 java 那樣好用，又在默認條件下不付出任何額外成本（cpu、內存、鎖等），並且還能跟 c 無縫對接，就會發現自己最終重新發明了一遍 c++。

這兩條加在一起的難度超乎想像。考慮到 c++ 發明時 cpu 的能力和當時的編譯理論，真的無法做到比 stl boost 更好了。看看同樣目標的的 rust，加持了 llvm 大殺器和 40 多年編譯理論的積累，那語法語意依舊奇葩。

或許今天萬眾創業、大眾創新的環境是我們誤認為軟體就應該是沒那麼多奇技淫巧就能搞出來的，真心不是這樣的！！！但凡有點兒技術的公司，都還是 c/c++ 兜底，因為隨著規模的增長，成本必須得到控制。天下沒有免費的午餐，python 的便利、java 的社區、摩爾定律，這些終究都不能為你消化每天 10 億 PV 帶來的成本。唯有用底層語言好好優化演算法一條路。

c++ 當然不是一門現代語言，我們熱切等待著 rust 的解放。