應用一些基本宏來簡化大型項目中的代碼是一個好主意嗎？

Question

我已經在基礎c ++庫上工作了一段時間，而且我有很多想法可以真正簡化代碼編寫和管理過程。 其中之一是引入一些宏來幫助簡化經常出現的語句，但比必要時復雜一點。

例如，我想出了這個基本宏來簡化最常見的for循環類型：

#define loop(v,n) for(unsigned long v=0; v<n; ++v)

這將使您能夠替換那些看起來如此笨重的笨重的循環：

for (int i = 0; i < max_things; i++)

使用更容易編寫的內容，甚至更高效：

loop (i, max_things)

使用這樣的約定是一個好主意嗎？ 使用不同類型的編譯器可能會遇到任何問題嗎？ 對於不熟悉宏的人來說，這會讓人感到困惑嗎？

Answer 1

恕我直言，這通常是一個壞主意。 您實際上是將眾所周知且理解的語法改變為您自己的發明。 不久你可能會發現你重新發明了這種語言 。 :)

Answer 2

我想說這取決於你是否希望其他人能夠理解你的代碼。 如果它只是你在那里，那么我沒有看到宏的問題。

如果其他人必須要查看此代碼，那么宏將導致問題。 另一個人不會知道他們是什么或他們做了什么（無論他們看起來多么可讀和明顯）並且當他們第一次遇到他們時將不得不去尋找他們。 結果將使您的代碼對除了您自己以外的任何人都不可讀 - 任何使用它的人都必須同時學習新的語言和程序。

而且，如果你希望代碼成為一個不僅僅是你個人用途的庫，那么它只是你處理代碼的可能性幾乎為零 - 那么我就不去做 。

Answer 3

不，不是個好主意。

  int max = 23;
  loop(i, ++max)...

但是，將常用代碼重構為可重用組件然后重用而不是復制是一個好主意。 您應該通過編寫類似於標准算法（如std :: find（））的函數來完成此操作。 例如：

template < typename Function >
void loop(size_t count, Function f)
{
  for (size_t i = 0; i < count, ++i) f();
}

這是一種更安全的方法：

int max = 23;
loop(++max, boost::bind(....));

Answer 4

我想你已經用你的示例用法提供了一個強有力的論據來反對這個宏。 您將循環迭代器類型從int更改為unsigned long 。 這與你想要做多少打字無關，那么為什么要改變呢？

循環的繁瑣指定了迭代器的起始值，結束值，類型和名稱。 即使我們假設最后一部分將始終是++name ，並且我們很樂意堅持這一點，您有兩種選擇 - 刪除一些靈活性或每次都輸入。 您已經選擇去除靈活性，但您似乎也在代碼庫中使用了這種靈活性。

Answer 5

在Unix中，我發現當我想要為命令創建一個別名時，我一直使用命令，我的命令就在我的手指上，而且我記得別名的語法比原始命令更難。

這同樣適用於此 - 當你使用成語這么多以至於你想為它創建一個宏時，這個成語會在你的手指上，並且比你輸入代碼更讓你感到痛苦。

Answer 6

擺脫for循環通常是一個好主意 - 但用宏替換它們不是。 我會仔細查看標准庫算法。

Answer 7

這是一個你在哪里獲得價值的問題。 在你的循環中輸入那15個額外的字符真的會減慢你的開發速度嗎？ 可能不是。 如果你有多行令人困惑，不可避免的樣板彈出到處，那么你可以而且應該尋找避免重復自己的方法，例如創建有用的函數，清理類層次結構或使用模板。

但是相同的優化規則適用於編寫代碼來運行它：優化小事情而效果不大並不能很好地利用時間或精力。

Answer 8

Steve Jessop提出了一個很好的觀點。 宏有它們的用途。 如果我可以闡述他的陳述，我甚至會說，支持或反對宏的論據歸結為“它取決於”。 如果你沒有仔細考慮制作你的宏，你就有可能讓未來的維護者的生活變得更加艱難。 另一方面，使用wxWidgets庫需要使用庫提供的宏來將代碼與gui庫連接。 在這種情況下，宏降低了使用庫的入口門檻，因為魔法的內部與理解如何使用庫無關，因此遠離用戶。 在這種情況下，用戶不必理解他們真正不需要知道的事情，並且可以認為這是對宏的“好”使用。 此外，wxWidgets清楚地記錄了如何使用這些宏。 因此，請確保您隱藏的內容不是其他人需要了解的內容。

或者，如果僅供您使用，請將自己敲開。

Answer 9

除了其他人提到的維護/理解問題之外，您還將很難打破並單步執行宏代碼。

我認為宏可能被接受的一個領域是用常量/文字填充大型數據結構（當它可以節省過多的輸入時）。 您通常不會單步執行此類代碼。