c++ - DRY 与“避免宏”

Question

我正在使用 Windows API 在 C++ 中创建自己的 XUL 实现。元素由 XML 解析器构造的事实要求它们具有相同的接口，这样我们就不需要为每个元素构造函数编写自定义代码。结果是我的大部分元素看起来像这样：

class Button : public Element
{
public:
    static const char * Type() { return "button"; }

private:
    friend class Element;
    Button(Element * inParent, const AttributesMapping & inAttributesMapping);
};


class Label : public Element
{
public:
    static const char * Type() { return "label"; }

private:
    friend class Element;
    Label(Element * inParent, const AttributesMapping & inAttributesMapping);
};


class Description : public Element
{
public:
    static const char * Type() { return "description"; }

    virtual bool init();

private:
    friend class Element;
    Description(Element * inParent, const AttributesMapping & inAttributesMapping);
};

所以这里有很多代码重复。我想知道用这样的宏调用替换它们是否是个好主意：

#define DECLARE_ELEMENT(ElementType, XULName)           \
class ElementType : public Element                      \
{                                                       \
public:                                                 \
    static const char * Type() { return XULName; }      \
                                                        \
private:                                                \
    friend class Element;                               \
    ElementType(                                        \
        Element * inParent,                             \
        const AttributesMapping & inAttributesMapping); \
};                                                      \


DECLARE_ELEMENT(Window, "window")
DECLARE_ELEMENT(Button, "button")
DECLARE_ELEMENT(Label, "label")

我还没有完全弄清楚这个概念，所以这里缺少一些东西，比如类定义，以及（也许）为每个元素添加方法的能力。

但我想知道您对在这种情况下使用宏的看法。随时分享您的想法。

编辑

我现在正在使用一个小的 ruby 脚本，它从一组模板生成源文件和头文件。我增强了脚本，以便文件也自动标记为在 SVN 上添加，并且修改了 Visual Studio 项目文件以包含这些文件。这为我节省了大量的体力劳动。我对这个解决方案很满意。仅供参考，这就是模板现在的样子：

#ifndef {{ELEMENT_NAME_UPPER}}_H_INCLUDED
#define {{ELEMENT_NAME_UPPER}}_H_INCLUDED


#include "XULWin/Element.h"


namespace XULWin
{

    class {{ELEMENT_NAME}} : public Element
    {
    public:
        static ElementPtr Create(Element * inParent, const AttributesMapping & inAttr)
        { return Element::Create<{{ELEMENT_NAME}}>(inParent, inAttr); }

        static const char * Type() { return "{{ELEMENT_TYPE}}"; }

        virtual bool init();

    private:
        friend class Element;
        {{ELEMENT_NAME}}(Element * inParent, const AttributesMapping & inAttributesMapping);
    };

} // namespace XULWin


#endif // {{ELEMENT_NAME_UPPER}}_H_INCLUDED

CPP文件：

#include "XULWin/{{ELEMENT_NAME}}.h"
#include "XULWin/{{ELEMENT_NAME}}Impl.h"
#include "XULWin/AttributeController.h"
#include "XULWin/Decorator.h"


namespace XULWin
{

    {{ELEMENT_NAME}}::{{ELEMENT_NAME}}(Element * inParent, const AttributesMapping & inAttributesMapping) :
        Element({{ELEMENT_NAME}}::Type(),
                inParent,
                new {{ELEMENT_NAME}}Impl(inParent->impl(), inAttributesMapping))
    {
    }


    bool {{ELEMENT_NAME}}::init()
    {
        return Element::init();
    }

} // namespace XULWin

score 39 · Accepted Answer

如果您使用模板解决方案，则可以避免使用宏并避免重复自己：

template <const char *XULName>
class ElementType : public Element
{
public:
    static const char * Type() { return XULName; }

private:
    friend class Element;
    ElementType(
        Element * inParent,
        const AttributesMapping & inAttributesMapping);
};

char windowStr[]="window";
char buttonStr[]="button";
char labelStr[]="label";

typedef ElementType<windowStr> Window;
typedef ElementType<buttonStr> Button;
typedef ElementType<labelStr> Label;

经验法则：模板几乎可用于 C 语言中需要宏的所有内容。

实现说明：字符串文字不能直接用作模板参数，因为它们具有内部链接——这就是你需要windowStretc 的原因。在实践中，你可能希望将windowStr,buttonStr和的声明放在labelStrH 文件中以及那些的定义CPP 文件中的字符串。

score 5 · Accepted Answer

我不会在这里使用宏。线索在你的类“描述”中，它有一个额外的成员函数init，而其他人没有。因此，您将无法使用宏来定义它，而是手动扩展宏并添加额外的行。

对我来说，这比写出所有的类定义更大地违反了 DRY。几乎不重复自己，但只为一种情况做，往往最终更难保持一贯的重复自己。DRY 是关于找到好的抽象，而不仅仅是减少样板。

SetAttributes不过，我可能会用class中的函数替换这些构造函数Element。这可能会减少每个派生类中实际需要的样板数量，因为构造函数是不能从基类继承的东西。但这取决于每个类的构造函数的实现有多相似。

score 5 · Accepted Answer

作为替代方案，您可以考虑在单独的构建步骤中生成代码，而不是使用预处理器。我喜欢cog，但你可以使用任何你喜欢的东西——这样你就可以完全以编程方式控制生成的内容。（宏很强大，但你能做的有限。）

score 4 · Accepted Answer

我认为宏可以在这样的低级别上减少重复（从而减少引入错误的风险）。

宏的使用将保持非常本地化，并且应该使整个代码更容易理解。当然，它也可能需要一些文档工作。

score 3 · Accepted Answer

使用任何使代码更简单的东西。

DRY 和 Avoid Macro 都有相同的目标：让你的代码更简单。

DRY：避免重复
避免宏：因为它们可能会引入难以诊断的编译器错误或难以诊断的错误（因为它们绕过命名空间边界并且不支持 C++ 感知/类型安全）。

像往常一样，我建议遵循精神而不是文字。在您的情况下，很明显该宏实际上会简化您的代码，因此您可能应该使用它。

但是，考虑到宏可能引入的问题，请确保将其命名为“安全”。例如，在开头包含项目名称/文件名以减少与现有宏的潜在“冲突”。

（您可以查看 BOOST 标头保护以了解命名约定）

score 3 · Accepted Answer

class如果您打算使用 doxygen 等自动代码文档工具，请谨慎使用宏来替换定义。在生成任何文档之前，您必须通过预处理器运行代码。也许不是最重要的考虑因素，但仍然需要考虑一些事情。

score 2 · Accepted Answer

恕我直言，这个宏是合理的。#undef DECLARE_ELEMENT虽然我认为添加以防止悬空宏会更好。（除非您也打算在其他文件中使用此宏。）

但是请注意，只有当这些类永远不会有太大差异（或完全不同）时，这才有效。

还有另一种使用模板的解决方案。考虑以下代码

namespace impl
{
    struct ButtonTag;
    struct LabelTag;


    template< typename TypeTag >
    struct NameGenerator;

    template<>
    struct NameGenerator< ButtonTag >
    {
        static const char * getName() { return "button"; }
    };

    template<>
    struct NameGenerator< LabelTag >
    {
        static const char * getName() { return "label"; }
    };


    template< typename TypeTag >
    class SimpleElement : public Element
    {
    public:
        static const char * Type()
        { return NameGenerator< TagType >::getName(); }

    private:
        friend class Element;

        SimpleElement(
            Element * inParent,
            const AttributesMapping & inAttributesMapping);

    };
}

typedef impl::SimpleElement< impl::ButtonTag > Button;
typedef impl::SimpleElement< impl::LabelTag > Label;

它有点冗长，但避免了宏。

score 1 · Accepted Answer

代码示例

enum Types { BUTTON, LABEL,...}

struct TypeList {
    static const char * Type(const int nID)
    {
         switch(nID) {
         case BUTTON: return "button";
         ...
    }
};

template<ID>
class IElem : public Element
{
private:
    static TypeList m_oTypeList;

public:
    static const char * Type() { return m_oTypeList.Type(ID); }
private:
friend class Element;
    IElem(Element * inParent, const AttributesMapping & inAttributesMapping)
    {...}
};

用于非常规功能和专门的

class Button : public IElem<BUTTON>
{
...
}

score 1 · Accepted Answer

我什至可以更进一步，在使用宏时同时使用单散列和双散列功能。单哈希创建字符串常量和双连接标识符以构建新的组合。

#define DECLARE_ELEMENT(ElementType)                     \
class C ## ElementType : public Element                  \
{                                                        \
public:                                                  \
    static const char * Type() { return # ElementType; } \
                                                         \
private:                                                 \
    friend class Element;                                \
    C ## ElementType(                                    \
        Element * inParent,                              \
        const AttributesMapping & inAttributesMapping);  \
}

DECLARE_ELEMENT(window); // defines Cwindow
DECLARE_ELEMENT(button); // defines Cbutton
DECLARE_ELEMENT(label);  // defines Clabel

例如，我有时会编写以下代码来测试某些常见类型的 sizeof。

#include <stdio.h>

#define OUT( _type ) printf("sizeof(%s) = %d\n", #_type, sizeof(_type))

int main() {
  OUT( char );
  OUT( int );
  OUT( short );
  OUT( long );
  OUT( long long );
  OUT( void* );
  return 0;
}

score 0 · Accepted Answer

在这种情况下，我会投票支持宏。毕竟它们并没有那么糟糕，你不应该尝试用它们编写内联函数，但除此之外它们很好。

score 0 · Accepted Answer

我认为在这种情况下使用宏是可以的，但前提是你

可以开发一个不太复杂但涵盖（最好）所有必要Element的类结构的解决方案
很好地记录宏
意识到某些 IDE 在宏生成的类结构方面存在问题，并且可以承受后果

score 0 · Accepted Answer

这段代码看起来非常像 Tom Cargill 在他的书“ C++ 编程风格”的第 1 章中剖析和重新组装的程序，该程序可以追溯到 1992 年。诚然，这段代码没有使用宏来复制几乎相同的类，但是网络结果从这里看起来非常相似。

c++ - DRY 与“避免宏”

12 回答 12

Related

Reference