ausserdem machen makros manchmal das debuggen schwieriger.

Wenn du mal mit wxWidgets arbeitest, wirst du das auch bemerken: Da wird dann irgendwo in deinem Programm in der Zeile "IMPLEMENT_APP"(ein Makro) deines Programms ein Haltepunkt ausgelöst und man klickt sich durch hunderte von wxWidgets Sourcedateien, um halbwegs zu verstehen, was eigentlich passiert ist...

Grüße,

Martin

Wenn du mal mit wxWidgets arbeitest, wirst du das auch bemerken: Da wird dann irgendwo in deinem Programm in der Zeile "IMPLEMENT_APP"(ein Makro) deines Programms ein Haltepunkt ausgelöst und man klickt sich durch hunderte von wxWidgets Sourcedateien, um halbwegs zu verstehen, was eigentlich passiert ist...

das habe ich mit meinen selbstgemachten makros auch schon

* Makro-Namen sind global, wenn man also nicht aufpasst und gute Namen verwendet kann es schnell zu Kollisionen kommen
(gut: "MY_PROJECT_NAME_XYZ", schlecht: "XYZ", mies: "max" (siehe windows.h, DANKE MICROSOFT!!!))

* Makros verwirren einige "Indexer" ala Intelli-Sense oder den VAX C++ Indexer, weiters können einige Debugger keinen Wert beim Mouse-Over anzeigen

* Makros führen oft zu schlechten Compiler-Fehlermeldungen (man weiss nicht wo in dem 100 Zeilen Makro der Fehler steckt)

* Makros als Konstanten sind pöse weil sie nicht "zuordenbar" sind (static const dagegen kann man einem Namespace und/oder einer Klasse zuordnen)

...

Andrerseits finde ich Makros wie BOOST_FOREACH schon ziemlich cool.
Und ich verwende selbst Makros um an gewissen Stellen Code-Duplizierung zu vermeiden (es gibt einige Sachen wo man das in C++ NUR über Makros sinnvoll hinbekommt)

Diese Haltung liest man hier immer wieder. Gibt's dazu auch eine Begründung?

Ich habe dir das in einen anderen Thread beantwortet, hier nochmal die Links daraus:

http://msdn2.microsoft.com/en-us/library/z3f89ch8(vs.80).aspx
http://www.research.att.com/~bs/bs_faq2.html#macro

cu André

... Makros sind nicht generell böse, sie haben nur einige Schwächen und man sollte die Probleme kennen ...

Ich würde eher sagen das man sich weitgehend an folgendes halten sollte:
Vermeide Makros wo möglich, verwende sie wo nötig

Der Vergleich mit der while-Schleife hinkt imho extrem. Ich kann jedes Sprachmittel missbrauchen um Fehler zu machen. Aber nichts desto trotz sind Makros keine Sprachmittel, sondern werden im Präprozessor textuell ersetzt. An sonsten kann man ja auch Viren zusprechen, denn auch normale Programme können theoretisch einen Datenverlust auslösen.

Es gibt ein, zwei Ausnahmesituationen wo auch ich Makros entgegen den obigen Spruch einsetzen würde. So z.B. Bei riesigen Typlisten (macht boost glaube ich so), weil die Templateschreibweise im Vergleich sehr extrem ist (n Templateverschachtelungen bei n Typen) und zu Tipfehlern verleitet. Wenn gleich ich bislang nicht vor dem Problem stehe... der Compiler an dem ich arbeite kommt mit Templates eh nur maginal zurecht (ganz zu schweigen von STL - was ist das, kann man das essen?).

cu André

Also ich finde while-Schleifen generell böse, weil ja eine Endlosschleife daraus werden kann

Nicht wenn du eine Quadcore-CPU hast! Die wird eine Endlosschleife ruck zuck fertig machen.

Aber nichts desto trotz sind Makros keine Sprachmittel, sondern werden im Präprozessor textuell ersetzt.

Und dennoch sind Makros ein Sprachmittel. Sie sind nur nicht so sehr integriert wie viele andere. Niemand hält dich davon ab, einen Compiler zu bauen, der das alles in einem Durchgang handhabt (außer vielleicht die Vernunft ;)).

asc schrieb:

Es gibt ein, zwei Ausnahmesituationen wo auch ich Makros entgegen den obigen Spruch einsetzen würde. So z.B. Bei riesigen Typlisten (macht boost glaube ich so), weil die Templateschreibweise im Vergleich sehr extrem ist (n Templateverschachtelungen bei n Typen) und zu Tipfehlern verleitet.

Macht Boost nicht. Im Allgemeinen hast du Template-Spezialisierungen bei den MPL-Containern. Um die zu generieren wird allerdings Boost.Preprocessor verwendent, ein grauenhaftes Stück schwarze Magie…

asc schrieb:

Aber nichts desto trotz sind Makros keine Sprachmittel, sondern werden im Präprozessor textuell ersetzt.

Und dennoch sind Makros ein Sprachmittel. Sie sind nur nicht so sehr integriert wie viele andere. Niemand hält dich davon ab, einen Compiler zu bauen, der das alles in einem Durchgang handhabt (außer vielleicht die Vernunft ;)).

asc schrieb:

Es gibt ein, zwei Ausnahmesituationen wo auch ich Makros entgegen den obigen Spruch einsetzen würde. So z.B. Bei riesigen Typlisten (macht boost glaube ich so), weil die Templateschreibweise im Vergleich sehr extrem ist (n Templateverschachtelungen bei n Typen) und zu Tipfehlern verleitet.

Macht Boost nicht. Im Allgemeinen hast du Template-Spezialisierungen bei den MPL-Containern. Um die zu generieren wird allerdings Boost.Preprocessor verwendent, ein grauenhaftes Stück schwarze Magie…

Naja, Boost verwendet Makros um Template Spezialisierungen zu erstellen. Genau das mache ich z.T. auch, weil man mit Vererbung/Template-Rekursion etc. eben nicht alles erschlagen kann.
Eben Dinge wie x<a1>, x<a1, a2>, x<a1, a2, a3> etc.
Oder Templates für Calling Conventions überladen (__stdcall, __fastcall etc.).

Naja, Boost verwendet Makros um Template Spezialisierungen zu erstellen. Genau das mache ich z.T. auch, weil man mit Vererbung/Template-Rekursion etc. eben nicht alles erschlagen kann.
Eben Dinge wie x<a1>, x<a1, a2>, x<a1, a2, a3> etc.
Oder Templates für Calling Conventions überladen (__stdcall, __fastcall etc.).

Ja?! Das hab ich doch auch geschrieben (wenn auch nicht mit perfekter Orthographie). Ändert aber auch nichts am magischen Charakter dieser Makros ;).

Und ja, ist "macro magic". Mal ne Abwechslung zu "template magic"