的astyle與--remove-支架和宏

隨着代碼：的astyle與--remove-支架和宏

#define MACRO(A,B) foo(A); bar(B) 

if(true) { 
    MACRO(A,B); 
}

的astyle將刪除周圍的宏調用

if(true) 
    MACRO(A,B);

括號幸運我找到了解決辦法。如果我將;放在宏中，Astyle會理解它。

#define MACRO(A,B) foo(A); bar(B); 

if(true) { 
    MACRO(A,B) 
}

這是一個很好的解決方案，它是Astyle的錯誤還是我的誤解？

來源

2014-10-31 nowox

這是風格非常不好的宏開始。它應該使用'do {...} while（false）'模式（沒有最後的';'）。 – unwind 2014-10-31 12:41:45

這也是一個可疑的風格，刪除括號... – DevSolar 2014-10-31 12:50:32

@DevSolar：這是一個可疑的風格，雜亂的東西與過度的括號，比較，換行符... – Deduplicator 2014-10-31 12:51:39

這是一種糟糕的風格。

如果你絕對必須有宏觀多條語句，在do while環（注意最後缺少分號）將它們包裝：

#define MACRO(A,B) do { foo(A); bar(B); } while(0)

來源

2014-10-31 12:42:06 user694733

甚至更好，您可以使用語句表達式和支持它們的編譯器。您可以獲得額外的好處，即您的宏可以像「真實」功能一樣返回一個值。 – 2014-10-31 12:46:02

順便說一句：在這種情況下，逗號運算符的工作原理是：'（foo（A），bar（B））' – Deduplicator 2014-10-31 12:49:12

@Dupuplicator：是的，但是考慮必須使用塊中的任何臨時變量。 – 2014-10-31 12:54:21

函數宏都是壞的作風，出於多種原因。較差的類型安全性，難以閱讀，難以調試/維護，令人難以置信的錯誤傾向，打開程序以適應各種不明確的行爲等等。

沒有大括號的控制或循環語句是危險的風格，因爲它使程序容易受到許多非常常見的錯誤的影響。有些人會爭論並說「沒有大括號使得代碼更易讀」（我本人曾經在這個營地中），然後他們會跳過去寫錯誤，因爲這樣。沒有大括號總是遲早會導致錯誤。

如果你總是使用大括號，那麼在編寫宏時就不需要使用各種晦澀難懂的技巧。

良好的樣式：

void function (type A, type B) 
{ 
    foo(A); 
    bar(b) 
} 

if(true) 
{ 
    function(A, B); 
}

來源

2014-10-31 12:51:25 Lundin

你**真的**想在這裏開始一場風格戰？ – Deduplicator 2014-10-31 12:52:51

如果你只針對GCC，我不會說功能類似的宏是壞的。例如，'typeof'擴展和一個語句表達式允許你編寫一個類型通用的'MAX'宏。 – 2014-10-31 12:56:07

@Deduplicator這不是風格，這是不好和危險的做法。這不是我的主觀個人觀點，MISRA-C等編程機構可以作爲參考。它是一個完全關注程序安全的文件，對編碼風格沒有任何限制。然而，它禁止類似函數的宏，並且爲了_安全原因，它禁止沒有大括號的控制語句。這反過來間接地基於實際的科學研究：已經對源代碼進行了人口研究，以確定軟件缺陷的常見原因。請參閱MISRA-C：2012指令4.9和規則15.6。 – Lundin 2014-10-31 13:03:03

的astyle與--remove-支架和宏

回答

相關問題