製作庫時應避免使用MACRO

庫提供了一個派生類，作爲模板參數派生。製作庫時應避免使用MACRO

例子：

class userclass : public lib::superclass<userclass> 
{}

正如你可以看到它的相當多的輸入。而且，「用戶類」應該始終作爲公共派生出來，才能正常工作。所以我想出了兩個看起來像這樣的MACRO：

#define SUPER(x) public lib::superclass<x> 
#define SUPERCLASS(x) class x : public lib::superclass<x>

用戶現在可以輸入任意一個。

class userclass : SUPER(userclass) 
{} 

SUPERCLASS(userclass) 
{}

但是，主要的問題是，包含頭文件時，宏SUPER和SUPERCLASS存在於用戶全局名稱空間中。

可以/我應該：

有保留的命名空間要求，但仍然默認爲公衆導出的一種方式？
原樣使用這些宏。
只需要用戶寫出完整的「public lib :: superclass」。

我正在使用vs 11，該庫針對Windows開發人員。

來源

2013-02-02 David

使用宏的第一條規則是「不要，如果有任何其他解決方案」。在這種情況下，還有另一種解決方案，所以擺脫它們。其次，你的宏的好處遠不止於此，因爲人們不知道他們通過閱讀擴展到什麼，而完整的定義卻是如此。說真的，你要保存一個真正可分辨的字符數量，真正可怕的可讀性。它遠遠優於簡單地寫出繼承。

來源

2013-02-02 12:41:56 Puppy

我做了很多維護工作。宏觀用戶位於恐怖分子，毒販，兒童虐待者和PHP開發者之下的階梯上。 –

@MartinJames：哪一個位於頂端，恐怖分子還是PHP開發人員？ ;-) – rodrigo

說實話，我認爲虐待兒童的人比PHP低，儘管其中並沒有很多。 –

這確實不是很多類型。我看過很多不應該縮短的線條。用宏隱藏它只是混淆了你的代碼。如果我快速瀏覽SUPERCLASS(userclass) {}，我幾乎可以猜測它是一個類（我不喜歡使用基於猜測的庫），但我不知道它或它的父類是否被稱爲userclass（或者都不是）或者它使用了什麼樣的繼承。這意味着你必須記錄它，並迫使人們在需要時查看它。

所以正確答案是選項3 - 不要使用宏。

^{如果你真的真的需要在你的庫中使用一個宏，給它一個庫特定的前綴。這與您到達命名空間宏的距離相近。}

來源

2013-02-02 12:42:45

我投3票。只需要用戶寫出完整的「public lib :: superclass」。

真的是有很多寫，
東西已被寫入多次
或要隱藏的醜陋的實現細節：

宏庫中，如果可以是有用的並且該語言不允許你做其他事情。

但在你的情況：

沒有這麼多寫，
是的，你必須把類名兩次，
你不想隱瞞事實，你是繼承，甚至是你正在寫一個類！

我不認爲類名的重複 - 一個積極點 - 是值得的。特別是因爲您將隱藏關鍵字class，並導致讀者相當混淆。

無論如何，如果一個庫使用宏習慣上把庫名中的所有宏的面前：

#define MY_FANCY_LIBRARY_NAME_SUPER(x) public lib::superclass<x>

但現在你是不是節省了這麼多的打字...

PS：記住編程的金科玉律：

代碼被寫入一次，但永遠讀，因而它應該很容易閱讀，比更容易寫。

來源

2013-02-02 12:46:07 rodrigo

製作庫時應避免使用MACRO

回答

相關問題