預處理器強制一致性，在C ++中是個好主意嗎？

Question

我剛剛讀了文章“慣用編程” ，它試圖強調一個重要的概念：語言不應該決定如何解決問題，而應該指出語言應該如何解決問題。

例如，作者選擇了C / C ++預處理器來做兩件事：

1. 增強一致性

2. 將語法和語法添加到現有語言。

現在，我知道這篇文章至少可以追溯到2003年並且使用的是C語言，但是我已經看到其他人之前至少使用過第1點（例如，Ogre 3D）。

給出的示例是：

#define property(name, type)   :                             \
                            type m##name;                \
                            public:                      \
                             type name()                 \
                                { return m##name; }      \
                             void name(type t__##name)   \
                                { m##name = t__##name; }  

像這樣使用：

class MyClass
{
  protected property(age, unsigned short);
  private   property(gpa, float);

  private:  // Other stuff can go here
};

除了宏是邪惡的，我們應該使用現代C ++變體這一事實之外，據我所知，沒有合適的替代解決方案，我相信這是Boost.Wave和Boost.Preprocessor用來澄清和增強的一種東西。

我相信這是有好處的，但是我想從使用過或看過這本書的人那里知道您的想法？ 作者的觀點和榜樣是否仍然具有優點，還是值得閱讀，靜默考慮並藏起來作為一個很好的竅門？

編輯

感謝您的回答！

我希望迅速闡述這個問題的性質。 不是“此示例好用還是不好？” 問題，這是作者提出的旨在豐富或增強現有語言的更改和擴展類型的示例。 因此，問題是：是否可以濫用該預處理器來添加語言擴展並基於該宏片段和其他宏片段的示例來實現一致性？

Answer 1

恕我直言，在這種情況下，用宏封裝屬性不會增加任何值，除了會稍微混淆代碼。 同樣，您不能編寫自定義的getter / setter並保持原樣。

我在兩年前曾經工作過的地方為一些常見的列表模式做了這種事情（在我的歷史記錄中搜索諸如C，宏，預處理器之類的標簽，然后感到驚訝！:-p

使用宏“高階函數”生成器的C函數編程

C函數裝飾器（包裝器）在編譯時 ），現在我認為這不是最好的主意。

當您執行“智能技巧”時，人們（和工具！）很容易感到困惑。 例如，在您的示例中，如果有人使用了IDE的自動完成功能，則可能不會顯示您的方法或屬性。

因此，除非您真的需要做一些聰明而強大的事情，否則您將擁有適當的工具並且在您的環境中是慣用的（考慮一下Python的數據模型，實際上您可以擁有屬性描述符或Common Lisp的宏），請嘗試將其制作為盡可能明確。 它將為您節省許多WTF面孔。

Answer 2

因此，如果我正確解釋了您的問題-您想知道使用setter / getters是否是一個好習慣。

我的個人經驗是，這些方法不會增加任何價值，不會增加代碼大小，因此不應使用。 相反，您應該將該成員變量公開。

但是請注意，對此問題有不同的意見 。

---

如果實現是一致的，那么這是一個好習慣。 但是，如果在某些情況下必須使用不同的吸氣劑/吸氣劑，則不要這樣做。

Answer 3

這種機智常常會破壞您直接使用的工具。 使用語言和基本類型可以找到更清晰的解決方案。 實際上，如果無法復制該值，或者您不想復制該值，這將很快消失。 因此，現實世界中所需的變體通常與使用內置語言功能，基本類型且沒有預處理器魔術的實現一樣復雜。 我確實采用這種方法來解決編譯器差異（非常罕見）並偶爾定義生成的類（然后將其封裝並提供適當的接口），僅此而已。