作为一种替代办法,你可以考虑制定一部单独的建筑步骤,而不是使用加工剂。 见cog。 但你可以使用你喜欢的东西。 这样,你们就能够全面控制产生的东西。 (Macros是强势的,但仅限于你所能做的事情。)

我认为,宏观办法可以减少重复性(从而减少出现错误的风险)的低水平。

宏观方法的使用仍将非常地方化,应当使整个守则更容易理解。 当然,这也可能需要一些文件工作。

无论怎样使用,该守则都更加简单。

南盟和避免马科罗这两个目标相同:使你的法典更加简单。

• DRY: avoid repetition
• Avoid Macro: because they can introduce hard to diagnose compiler errors or hard to diagnose bugs (as they bypass namespace boundaries and are not C++ aware / typesafe).

因此,与准则一样,我建议遵循精神而不是文字。 在你看来,似乎很明显,宏观将实际简化你的法典,因此,你可能应当加以利用。

然而,考虑到宏观因素可能带来的问题,确保安全地命名。 在开始时列入项目名称/名称,例如减少与现有宏观冲突的可能性。

(你可以看望BOOST的警卫,了解命名公约的想法)

如果你计划使用自动编码文件工具,如氧气,则使用替代<代码>}/代码>定义的宏观方法。 在生成任何文件之前,你必须先通过加工商操作该守则。 也许不是最重要的考虑,而是需要考虑的问题。

IMHO这一宏观是合理的。 虽然我认为最好添加<条码>第11条之规定——ELEMENT,以防ling宏观。 (除非你计划在其他档案中使用这一宏观方法)

但请注意,只有这些班级永远不会差别很大(或最多)。

还有一个使用模板的解决办法。 考虑采用以下守则:

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;

然而,它比宏观更有利。

编码样本

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>
{
...
}

我甚至可以更进一步,在使用宏观产品时,可以同时使用单一散射和双壳。 单一散射线会形成固定不变,并形成双重加固的识别特征,以建立新的组合。

#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

例如,下面的法典是我有时为了测试某些共同类型的规模而写的。

#include <stdio.h>

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

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

我将对这一案例进行宏观表决。 他们肯定说,毕竟是坏的,你不应试图与他们一道书写行文,但不是好事。

我认为,在这种情况下,使用宏观方法是站不住脚的,但只有你才能这样做。

• can develop a solution that is not too complex but covers (preferably) all necessary Element class structures
• document the macro well
• are aware that some IDEs have problems with macro-generated class structures and can live with the consequences

该法典在“