预处理器强制一致性，在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

这种机智常常会破坏您直接使用的工具。 使用语言和基本类型可以找到更清晰的解决方案。 实际上，如果无法复制该值，或者您不想复制该值，这将很快消失。 因此，现实世界中所需的变体通常与使用内置语言功能，基本类型且没有预处理器魔术的实现一样复杂。 我确实采用这种方法来解决编译器差异（非常罕见）并偶尔定义生成的类（然后将其封装并提供适当的接口），仅此而已。