我已經編寫了C++和Java很長一段時間了，並且對通用C++架構有一些疑問。Common C++架構
當我在Java中編程時，我嘗試模仿標準庫，即使用接口（如Iterable和Serializable）以及具有類似的命名約定和功能。但是，使用C++時，我試圖模仿STL約定（除了迭代器）猶豫不決。
我煮它歸結爲以下幾個問題（是實現以下共同約定）：
或者是C++不值得mimicing在所有性病？
感謝您的意見/答覆！
我用C++越多，就越不喜歡模仿我找到的最好的庫。當我們獲得團隊中的初級開發人員時，問題就出現了。他們會理解基礎知識，但不瞭解語言的微妙之處。他們可能知道如何使用模板語法創建映射或列表，但在應用於其他對象時無法理解它。除了解決問題或推進產品之外，調試和執行代碼讀取所增加的複雜性也需要寶貴的時間。
我已經成長爲傾向於使用該語言的最基本功能，這通常會使代碼處於更自然的可讀狀態。當我回到8-12個月後，用代碼尋找一個不明確的錯誤時，我對這種方式的偏差感到後悔。另一方面，Java具有更簡單的庫實現，這對更多初級Java開發人員來說是很好理解的。我發現初級Java開發人員傾向於對初級C++開發人員的語言有更深入的瞭解。據說，由於成爲中級C++程序員所需的思想水平較低，C++開發人員有更多機會成爲真正的勝任者。
我不買「增加的複雜性」。就我而言，標準庫在降低複雜性方面非常出色。確實，*寫*易於使用的通用庫很難，但它總是如此。拋開這些特性*會大大增加客戶端代碼的複雜性。 – 2012-03-07 15:00:34
聽起來像他們在教Java比Java更好。另外，如果你有很多初級開發者，那麼你將不得不用任何語言來貶低東西。我也在Python和C中遇到了這個問題。你會感到驚訝，或者你不會，有多少初級開發人員不明白你爲什麼想要一個指針指針。 – 2012-03-07 15:04:14
那麼......螺絲C++的標準風格，讓我自己的框架風格？ – 2012-03-07 16:42:40
它很大程度上取決於您的項目。一般的建議似乎是：不要打擾擁有C++的具體標準。
E.g. typedefs有「for」和「against」兩種意見。
爲什麼C++中的具體編碼風格在C++中不太重要的原因是因爲該語言沒有提供強制執行和檢查這些風格的方法。 也就是說語法不容易分析，因此幾乎沒有工具可以有效地檢查/重構C++代碼。 這意味着風格檢查的重量落在程序員的肩膀上。即在風格指南之前就沒那麼有意義了，因爲那樣大部分的時間都被浪費在手工風格檢查上。
所以，只要使用任何你的項目/公司使用或決定使用。
這裏是我的個人喜好：
分配器：沒有意見。如果你需要一個自定義分配器，你可能會比我更瞭解如何處理它。
接口：如果你正在做任何性能敏感的工作 - 不要。他們在實時應用程序中讓事情明顯變慢。抽象虛擬類和pImpl模式。
模板而不是抽象基類：這取決於。但一般的意見似乎是模板應該用於類似容器的功能和一些其他簡單的情況。否則，這是一個體面的模式。調試這些仍然是一個嚴重的痛苦，將在未來幾年。
限制異常投擲：是的，那樣做。儘量不要使用例外，因爲信不信由你，在2012年，它們還沒有得到普遍支持。
使用typedefs：：只要嘗試使用C++ 11的std :: auto。否則，它們會讓你的生活更加艱難，因爲它們已經到達了＃定義宏的一半。我個人使用IDE（或Vim）來緩解長名稱的打字壓力並寫出長名稱。
模板有很多很難解釋的力量。 Alexandrescu用* Modern C++ Design *做了很好的嘗試。 – 2012-03-07 15:06:21
Re：限制異常拋出 - 你有這樣的例子嗎？我從來沒有見過最近的編譯器，即使在嵌入式領域也是如此。 – Collin 2012-03-07 15:09:57
我的意思是限制異常拋出只是在（大部分或全部）方法中使用throw（...）關鍵字。 – 2012-03-07 16:33:41
嗯。這很難以有意義的方式回答。你真的在問六個不同的大問題。 「爲什麼STL使用」，對於<全部點>中的x。這太多了。我投票結束這個問題是因爲它的範圍過於寬泛。試着問一下其中的一個。例如「爲什麼STL使用分配器？我從來沒有使用它們，我想知道爲什麼它們在那裏，我應該編寫自己的類來由分配器參數化嗎？」，例如。 –
2012-03-07 14:58:09
好吧，如果我把它們分成更多的問題，它們都會是這樣的： 使用分配器來定製容器是否通用？ 使用接口是否通用？等等......對於我自己的項目，我更喜歡遵循良好的做法，那麼從我的項目跳到其他人的項目更小。所以我真正想知道的是，「遵循STL風格編碼是否是一種好的做法？」。 – 2012-03-07 16:54:33