D.R.Y по сравнению с “избегают макросов”

Если вы используете шаблонное решение, вы можете избежать макросов и , чтобы не повторяться:

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.

Примечание по реализации: строковые литералы нельзя использовать непосредственно в качестве аргументов шаблона, потому что они имеют внутреннюю связь - вот почему вам понадобится windowStr и т. д. На практике вам нужно поместите объявления windowStr , buttonStr и labelStr в файл H, а определения этих строк в файл CPP.

В качестве альтернативы вы можете подумать о создании кода на отдельном этапе сборки вместо использования препроцессора. Мне нравится cog , но вы можете использовать все, что захотите - таким образом вы получаете полный программный контроль над тем, что создается. (Макросы - это мощный инструмент, но их возможности ограничены.)

Я думаю, что макросы могут помочь уменьшить повторение (и, следовательно, риск появления ошибок) на таком низком уровне.

Использование макросов останется очень локализованным и должно сделать код в целом более понятным. Конечно, это также может потребовать некоторых усилий по документации.

Используйте все, что упрощает код.

DRY и Avoid Macro преследуют одну и ту же цель: сделать ваш код проще.

• DRY: избегать повторений
• Avoid Macro: потому что они могут привести к трудным для диагностики ошибкам компилятора или трудным для диагностики ошибкам (поскольку они обходят границы пространства имен и не учитывают / не поддерживают типы C ++).

Как обычно, с рекомендациями, я бы посоветовал следовать духу, а не букве. В вашем случае кажется очевидным, что макрос на самом деле упростит ваш код, поэтому вам, вероятно, следует его использовать.

Однако, принимая во внимание проблемы, которые могут возникнуть при использовании макроса, не забудьте назвать его «безопасно». Включите имя проекта / имя файла в начало, например, чтобы уменьшить потенциальное «противоречие» с существующим макросом.

ИМХО этот макрос оправдан. Хотя я думаю, что лучше было бы добавить #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;

. Он несколько более подробный, но без макросов.

Остерегайтесь использования макросы, которые заменяют определения класса , если вы планируете использовать инструменты автоматической документации кода, такие как doxygen. Вам нужно будет запустить код через препроцессор перед созданием любой документации. Это, пожалуй, не самое важное соображение, но, тем не менее, о чем стоит подумать.

примеры кода

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

Например, приведенный ниже код - это то, что я иногда пишу, чтобы проверить 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;
}

Этот код очень похож на программу, которую Том Каргилл анализирует и повторно собирает в главе 1 своей книги « Стиль программирования C ++ », относящейся к 1992 году. По общему признанию, этот код не использовал макросы для копируют почти идентичные классы, но конечный результат выглядит ужасно похожим отсюда.

В этом случае я бы проголосовал за макросы. В конце концов, они не так уж и плохи, вы не должны пытаться писать с ними встроенные функции, но в остальном они хороши.

Я думаю, что в этом случае можно использовать макросы, но только если вы

• сможете разработать решение, которое не будет слишком сложным, но покрывает (предпочтительно) все необходимые Элемент структуры классов
• хорошо документируют макрос
• знают, что некоторые IDE имеют проблемы со структурами классов, сгенерированными макросами и могут жить с последствиями