Welche Compiler Flags benutzen und was bedeuten sie (g++) ?

Hallo alle zusammen,

ich bin relativ neu in der Programmierung und dem drum herum. Mich würde mal interessieren, welche Compiler Flags üblicherweise benutzt werden wenn man debugged und letztendlich ausliefern/testen möchte.

Habe schon ein bisschen gegoogled. Dort folgendes erfahren:

Zum debuggen: -O0 , -wall , -g
Für Release/Tests: -O2

und man kann wohl auch - O3 benutzen, aber das habe ich nicht so ganz verstanden.
Gibt es noch irgendwelche anderen Compilerflags? Ich meine mich erinnert zu haben das mal jemand sowas geschrieben hat:

debug: g++ -O0 -wall -g -64

also mit einer Zahl hintendran. Was hat es damit auf sich?

vielleicht kann mích jemand diesbzgl. aufklären !

Liebe Grüße

Hi,

also ich nutze diese Flags für Release:
-march=native -O2 -Wall -Wextra -pedantic -Wswitch-default -Wfloat-equal -std=c++0x -Wc++0x-compat

Für Debug nutze ich g++ nicht.

Youka

-O0: Optimierungslevel 0
Code wird nicht optimiert, sodass der eigene Code unverändert behandelt werden kann.

-Wall: aktiviert alle Standard-Warnungen
Fragwürdige Stellen werden erwähnt, um bereits zur Kompilierung Fehler zu entdecken.

-g: generiert Debugging-Informationen
Der Debugger nutzt diese Informationen, um Fehler identifizieren zu können.

-64: generiert Code für 64 Bit Maschinen
Nutzt die Fähigkeiten 64 Bit fähiger Prozessoren effektiver.

An sich ist es für einen Debug-Build besser, eben nur die nötigsten Flags zu setzen, welche du bereits erwähnt hast. Den Rest sollte man dem Standard des Compilers überlassen, der weiß schon, was richtig ist

SeppJ

Programmieren und gucken, ob es compiliert:
-Wall -Wextra -std=c++11
Schaltet alle Warnungen an und den neuesten Standard, den ich in der Regel nutze. Letzterer Schalter kommt halt drauf an, ob man diesen nutzt oder eben nicht. Man könnte auch noch Warnungen zu Fehlern machen, aber ich bin selber in der Lage, mich zu zwingen, alle Warnungen zu beheben.

Erster Test (d.h. einmal durch valgrind jagen):
-Wall -Wextra -std=c++11 -g
Manchmal noch ein redundantes -O0, einfach so zum Spaß

Bei Fehlern, die ich damit nicht beheben konnte (sehr selten):
-Wall -Wextra -std=c++11 -D_GLIBCXX_DEBUG
-D_GLIBCXX_DEBUG aktiviert den Debugmodus der C++-Standardbibliothek und ist einer der großen Vorteile von C++. Ein guter Grund es einmal damit zu versuchen. Es ist zwar sehr selten, dass ich in dieser Phase einen Fehler mache, der dadurch gefunden wird, aber zweimal hatte ich damit schon Erfolg. in der Regel sind meine Fehler, die nicht von valgrind gefangen wurden, aber zu kompliziert für diesen Schalter. In dieser und der vorherigen Phase werden manchmal auch Optimierungsoptionen eingeschaltet, wenn ein Debugrun ohne Optimierungen zu lange dauern würde. Ist zwar schlecht für die Aussagekraft der Informationen, die man erhält, aber manchmal eben einfach nötig.

Release, kleine Tools:
-Wall -Wextra -std=c++11 -O3
O3 liefert meiner Erfahrung nach im Schnitt die schnellsten Ergebnisse. O2 ist auch ok.

Release, große Programme:
Kommt drauf an. Neben O3 oft auch noch flto, manchmal auch march=native, oder, wenn ich ganz fancy bin, sogar profile guided optimization. Das sind an sich alles verschiedene Optimierungsoptionen, die aber ein Programm auch langsamer machen können. Daher testen! Je nachdem, wie oft ich erwarte, ein Programm zu nutzen und wie wichtig Geschwindigkeit ist, desto mehr Zeit nehme ich mir zum Testen der Optimierungen. Wenn ich faul bin, dann nehme ich wie oben bloß O3. Ist gut genug.
Bei Crosscompiling kommen eventuell noch solche Optionen hinzu, wie sie hier im Thread schon genannt wurden, wie -64. Oder ein anderes -march. Eventuell sogar -static für den Linker. Aber zum Glück ist die Notwendigkeit dafür bei mir in den letzten Jahren gegen Null gegangen, weil meine Plattformen homogener sind. Ich habe das immer gehasst.

Tatsächliches Debuggen (habe ich nur sehr selten nötig):
-Wall -Wextra -std=c++11 -ggdb3
Die zusätzlichen Informationen von -ggdb3 gegenüber -g benutze ich zwar nie, aber kostet auch nichts, sie zu aktivieren. Außerdem noch Debugschalter, die ich eventuell in meinem Programm eingebaut habe.

Optionen, die ich nie nutze, die man aber oft sieht:
Ofast. Verändert das Programmverhalten. No-go.

Wie man sieht: Wall und Wextra sind bei mir immer Pflicht.

Vielen Dank euch! Und ein großes Danke an Sepp für die vielen Erklärungen! Das hat mir sehr weitergeholfen.