C++ 模版元編程對快速開發原型有何幫助？

01-26

我在facebook開源的模版庫facebook/fatal · GitHub看到他的介紹：The goal is to speed up prototyping of complex software, while abstracting the complexity of template meta-programming and making its benefits available to a wider audience other than hard-core library writers.
有這些問題：

如果能：
然後他舉了些該lib的能力，int、string、map、list。包括用法：

這些設施不是讓代碼更複雜難以閱讀維護了嗎？它怎麼解決第一張PPT提到的痛點呢？請大大賜教。
PPT地址：fatal/cppcon2014.pdf at master · facebook/fatal · GitHub

僅從編譯、執行等方面看，題主舉例的引入模板元編程貌似沒帶來什麼好處，反而複雜了、效率也低了。但是，Facebook作為一個互聯網公司，是要以服務客戶為手段來獲利的，它不是個研究機構，所以它的開發是帶有工程性的。

工程性的軟體開發，通常是需求驅動的，以贏利為目的的。這就帶來如下問題：(1) 軟體開發完了，需求變了怎麼辦？回答是：沒辦法，為了賺錢，就得滿足客戶，就只好改唄！(2) 那進而又出來新問題，代碼太難改，修改成本過高的話會入不敷出啊！怎麼才能讓寫好的軟體改起來更方便？當-當-當-當！祭出「模板元編程」大法！

1、首先分析需求，獲得要待解決問題領域的概念模型。

2、分析概念模型，抽象出核心引擎框架，利用模板將這些核心引擎實現出來。

3、這些模板相當於構建出一層新的語法糖，實際開發人員只要學會使用這些語法糖來構建目標軟體即可以了。

上述方式怎麼就可以解決需求變化帶來的軟體可維護性問題呢？這裡，解決此問題的前提就是已經把會導致修改成本很高的那部分變化通過模板方式給隔離出來了，屆時只需要修改引擎代碼，只要引擎對外的介面及形式不變，引擎內部實現就可以任意變化。

還有一個問題，引入模板後，不是開發變得複雜了么？解決辦法是把開發人員劃分為兩部分，一部分專註於引擎開發，或者叫框架開發也行；另一部分是實際應用的開發。前者要保證引擎框架概念模型完整、自洽、穩定；後者只要理解了引擎模型的概念，學會一套基本穩定的語法糖，開發目標軟體時就不會覺得複雜了。

我並沒有詳細研究過「模版元編程」與「快速開發原型」之間的關係。但是從一些常識來分析一下。首先 template 這個東西和 type 與 type-safe 有密切的聯繫。而 static type check 的作用，在於大型 code base 的長期維護。它可以讓維護者在改動大 code base 時施行一些形式驗證，在部分程度上保證改動的正確性（比如說刪掉無用的 function，或者把直接變數訪問變成 accessor，等等）。

快速原型開發則是儘快跟上人腦的思維，不求 100% 的正確性，只求 main case 儘快走通。所以快速原型開發是摒棄 static type check 的。常用動態語言。非用 C++ 等作 prototyping，可以通過各種手段避開類型檢查。

兩者的基本出發點就是矛盾的。我覺得談不上什麼幫助。如果真的有幫助，大概也是一種比較扭曲很難流行的思維模式。

大多數互聯網公司首先是個商業公司，其次才是技術公司
facebook的垃圾也是垃圾，不會因為貼了facebook的標籤就成寶了

我覺得題主對這段話理解不太對，英文原文並沒有直接提到C++模板元編程與快速開發原型有什麼關係。

The goal is to speed up prototyping of complex software

這一句是說facebook/fatal這個庫，對於開發複雜軟體很有用，那麼它們指的複雜軟體是什麼，下句

while abstracting the complexity of template meta-programming and making
its benefits available to a wider audience other than hard-core library
writers

可推知，此處它們用複雜軟體專指大量使用C++元編程技術的軟體。

總的意思就是說，按照fatal的思想，去進行元編程會更簡單，更快捷（speed up prototyping），可以掩蓋元編程的複雜度（abstracting the complexity）。

元編程作為C++的黑科技，本就沒有統一的規範，它是一系列技巧的合集。stl和boost對這些技巧的使用具備很好的指導意義，自然而然就成了默認的規範。但也有其他比較受認可的用法，如Loki。

簡單看了一下fatal，大量使用C++11新特性，相比以前stl和Loki那些用法多是基於C++03的，C++11的新語法很多都是針對元編程而設計的，有了這些新特性，元編程大牛們各出奇招，拼湊出新的技巧，當然也就有人想到了隱藏這些晦澀的技巧，設計更友好的介面，讓更多人可以使用元編程。

元編程是編譯期（compile-time）圖靈完備的，它被做成簡化的介面也容易理解，這就像我們在運行期（run-time）也會把常用的東西封裝成庫，比如說，socket介面非同步通信調用系統函數處理很麻煩，於是有人把它們封裝成非同步事件庫，像libevent，libev，boost::asio之類。

我們在普通程序中操作的是變數，而在元編程中操作的類型，因此後者庫的概念和通常的庫也有區別，它更多是一種使用上的規範。

除了Type Rich的部分外，在其他的地方引入模板，除了增加你的編譯時間外，好處不那麼明顯。

泛型的部分，除了基礎庫外，不要盲目引入。

用STL和Boost。

要快速開發原型，為什麼不用Python？

C++模板元編程常用來開發庫，也就是說要庫的開發者需要，Fatal看起來像是更方便的開發庫的一種模板庫？