Makros in C++

audacia

In welchem Umfang haltet ihr die Verwendung von Makros in C++ für vertretbar?

Derzeit schreibe ich ein kleines Factory- und Plug-in-Framework. Der Benutzer muß, da C++ das für Templates nicht implizit macht, statische Klassenmember explizit instantiieren, was auf Dauer etwas häßlich aussieht. Deshalb habe ich die folgenden Makros definiert:

#define UCL_OO_DEFINE_FACTORY(type)                            \
    template <> ucl::oo::FactoryBase <type>::instantiator_t     \
        ucl::oo::FactoryBase <type>::instantiator

 #define UCL_OO_DEFINE_HELPERINTERFACE(type)                        \
    template <> ucl::oo::HelperInterfaceBase <type>::instantiator_t \
        ucl::oo::HelperInterfaceBase <type>::instantiator
#define UCL_OO_DEFINE_PLUGINMGR(plugindescriptor,baseclass)         \
    namespace ucl { namespace oo { namespace detail {               \
    static ucl::oo::PlugInHostDeclarator _phd (plugindescriptor,    \
        detail::_tryCast <baseclass, PlugInBase>,                   \
        typeid (baseclass).name ());                                \
    } } }

Wie zu sehen ist, nehmen diese Makros eine Menge an Schreibarbeit ab. Gibt es gute Gründe, hier nicht Makros zu verwenden? Ist das jetzt schlechter Stil?

Es ist schlechter Stil, die #undef wegzulassen, wenn die Makros nicht mehr benötigt werden.

drakon

Makros sind schlechte Stile in C++, aber wie du sagst, können sie einiges an Arbeit abnehmen. Das Problem von Makros sind hald, dass sie die Typensicherheit zerstören und unangenehme/schwer auffindbare Fehler erzeugen können.

Neudefinition eines Makros könnte eintreten, falls jemand den gleichen Namen benutzt und der Compiler entdeckt davon keine Spur. (Was bei dir aber eher unwahrscheinlich ist).

Ich würde bei dir jetzt aber eher ein typedef nehmen.

audacia

drakon schrieb:

Das Problem von Makros sind hald, dass sie die Typensicherheit zerstören und unangenehme/schwer auffindbare Fehler erzeugen können.

Da die hier gezeigten Makros sich auf eine sehr überschaubare Anzahl an Vorkommnissen beschränken werden, schätze ich das Fehlerpotential durch die Typsicherheit als gering ein, zumal sie hier nur als Deklarationsabkürzung und nicht als inline-Funktionsersatz benutzt werden. Schwerer wiegt vermutlich die Undurchsichtigkeit sowie die kryptischen Fehlermeldungen (die aber bei Templates ohne Concepts genauso vorkommen ).

Meine Einstellung zu Makros ist eigentlich recht entspannt. Wann immer sie entbehrlich sind, wo also typedef, static const unsigned oder static const char* den gleichen Effekt erzielen, verzichte ich, insbesondere aufgrund der Namespace-Agnostizität, gerne auf sie. Aber es gibt leider immer wieder Stellen, wo sie mir unverzichtbar scheinen - in meinem aktuellen Projekt eben diese drei.

drakon schrieb:

Neudefinition eines Makros könnte eintreten, falls jemand den gleichen Namen benutzt und der Compiler entdeckt davon keine Spur. (Was bei dir aber eher unwahrscheinlich ist).

Sehe ich auch so. Viel eindeutiger kann ich sie wohl nicht benennen. Auf die korrespondierenden #undefs muß ich aber verzichten - oder wo sollten diese stehen? Im Header? Dann kann ich die Makros im Quelltext nicht mehr benutzen.

drakon schrieb:

Ich würde bei dir jetzt aber eher ein typedef nehmen.

Wie würdest du das denn bitte anstellen wollen?

drakon

Hmm...
Habs mir nicht so genau angeschaut.

Aber hier sind sie wirklich so vertretbar. Benutze sie ja auch.

Ich meine wir fahren ja auch alle Auto, obwohl wir wissen, dass man das nicht SOLLTE.

Erhard Henkes

Ich meine wir fahren ja auch alle Auto, obwohl wir wissen, dass man das nicht SOLLTE.

Sonst geht's aber noch?

Artchi

Also Bjarne Stroustrup hat in seinem Buch geschrieben: Sobald man Makros einsetzen muß, zeigt dies eine Schwäche in der Sprache. Soll heißen, wenn du absolut keine C++-Sprachlösung finden kannst, muß üblerweise das Makro herhalten. Gleichzeitig sollte man vielleicht über eine Sprachverbesserung nachdenken, damit man nicht mehr die Makros benutzen muß.