在設計C++類的多種功能，假設我有以下兩種選擇：C++設計：單一功能執行多項任務VS執行單一任務
選項1：一種方法是用長參數列表和方法執行多個任務。
選項2：爲每個任務分開的方法（每個方法將有較小的參數列表）。
顯然，在一般情況下，選擇2是優選的，因爲它產生更乾淨的代碼。然而，如果這些方法只是爲了成爲其他方法的「助手」，那麼在選項2的情況下，我將不得不承擔多個函數調用的開銷，而選項1只會有一個函數調用。
將在所謂的性能增益（由於較少的函數調用）證明在這樣的（極端）的情況下，選擇選項1？
假設的性能增益（由於函數調用較少）是否有理由在這種（極端）情況下選擇選項1？
IMO，這裏的性能增益足夠可以忽略不犧牲代碼的可維護性，特別是在企業應用中，具有大的參數列表和大量的代碼行的功能是很難修改/調試。這些功能必須分解成多個較小的功能，其中每個功能都執行一個定義明確的步驟，這是更大任務的一部分。
你的工作是編寫好的，乾淨的工作代碼。編譯器的工作是使其高效。顯然，它做得更好，然後你就可以做到。
所以，總是選擇第二個選項。如果你想提高效率，那就寫乾淨的，讓編譯器做它的工作。 （順便說一句，你可以用-O3標誌編譯加大優化更進一步）
給一個實體，一個凝聚力的責任 是第5條在C++標題由Alexandrescu的編碼標準。
在我看來，你會失去清晰度，增加維護成本，並有更大的機會在「做這一切」的設想引入錯誤。
它可能是明智的測量單獨的函數的調用性能VS具有在每個呼叫內部執行代碼路徑邏輯的功能。
是擴展功能（即少函數調用）將是有益的是在嵌入式系統中，其中過頭可能不存在的情況下，唯一的一次。 – M4rc
@ M4rc，謝謝你的迴應。我想知道是否沒有任何編譯器切換到真正的「內聯」函數，以便優化嵌入式系統的編譯代碼！ – Vikdor
立即想起我想象不到，儘管禁用優化理論上應該儘可能地使可執行文件儘可能地接近您的可執行文件類型，從而爲您提供更多的控制。但與其他任何東西一樣，它只是*一個建議。不過，我相當確定嵌入式C/C++編譯器對這種情況包含了不同類型的優化。 – M4rc