ZFX + Developia

dot hat geschrieben:Eine bessere Lösung wäre wohl, ein entsprechendes .props File anzulegen und einfach in jedes neue Projekt zu importieren. Wenn du manuell eine .vcxproj Datei kopierst, dann musst auf jeden Fall auch bedenken, manuell eine neue GUID für das Projekt zu generieren und entsprechend im Project File auszutauschen, sonst gibt's potentiell Probleme spätestens sobald du mal mehr als ein solches Projekt in der selben Solution haben willst. Und den Default Project Namespace willst du vermutlich auch anpassen...

Die GUID wir von VS automatisch geändert, sobald man das neue Projekt in die Solution mit dem existenten einfügt.
Default Project Namespace? Ist das eine C# Einstellung? Ich rede von C++ Projekten. Um die gehts in diesem Thread ja.

kaiserludi hat geschrieben:Die GUID wir von VS automatisch geändert, sobald man das neue Projekt in die Solution mit dem existenten einfügt.

Ok, cool, das wusste ich nicht. Dann lag ich da wohl falsch^^

kaiserludi hat geschrieben:Default Project Namespace? Ist das eine C# Einstellung? Ich rede von C++ Projekten. Um die gehts in diesem Thread ja.

C++ Projekte haben sowas auch. Bin mir ehrlich gesagt selbst nicht sicher was genau den verwendet, vermutlich C++/CLI oder C++/CX Zeug...

Das größere Problem ist, dass dauernd irgendwas kaputtgeht. Irgendwann kann man z.B. das Toolset nicht mehr ändern oder bestimmte Dateien nicht mehr löschen oder MASM nicht mehr aktivieren – wenn man das Projekt komplett neu anlegt, mit identischen Einstellungen, geht es wieder. Passiert teils auch mit automatischem Update bei neuer Visual Studio-Version.

Dazu trägt auch bei, dass Visual Studio sehr fehlertolerant mit Projektdateien umgeht. Teils kann man falsche Pfade reinschreiben und Visual Studio findet die betreffenden Dateien trotzdem. Nur beim Build kracht’s dann.

Dot hat schon recht damit, dass props der sauberere Weg wären. Allerdings wäre das eine zusätzliche Abhängigkeit, und eine recht fiese dazu (eine fehlende Props-Datei aus dem Projekt zu kriegen ist nichts, was ein Anfänger mal schnell meistert). Die Props müssten also irgendwo in Projektnähe abgelegt werden, und dann bin ich wieder genau da, wo ich vorher war.

Ich versteh das Problem nicht ganz, .props file einfach neben das Projekt gelegt und fertig!? Mach ich andauernd, funktioniert wunderprächtigst...

… dann verlieren sie den Vorteil, dass man sie zentral ändert und die Änderungen überall angenommen werden.

Ungefähr wie ein Header, der nur ein einziges Mal #includet wird.

Aber Zeit beim Erstellen des Projektes würde es mir schon sparen, ja.

Visual Studio 2019 bringt den Schalter /d2FH4 mit, der die Größe der Exception-Handling-Metadaten drastisch reduzieren soll.

Er muss in den Projekteigenschaften der Befehlszeile des Compilers hinzugefügt werden. Standardmäßig ist er nur deshalb nicht an, weil die Anpassungen für die Windows Runtime es nicht mehr ins Release geschafft haben.

Ich nutze keine Exceptions, aber dem einen oder anderen dürfte das eine ganz willkommene Optimierung sein!

/d2OptimizeHugeFunctions – Visual C++ optimiert funktionen ab einer gewissen Größe nicht mehr (um die Kompilierzeit zu reduzieren). Die entsprechende Warnung muss von Hand aktiviert werden, und nach der Angabe von /d2OptimizeHugeFunctions werden Funktionen jeder Größe voll optimiert.

Ich konnte diese Größe in meinen Tests bisher nicht erreichen, daher hat mir der Schalter noch nichts gebracht.


/Zc:throwingNew korrigiert eine alte Marotte von Visual C++: Ganz ganz früher warf new bei Fehlschlag keine Ausnahme, sondern lieferte NULL zurück. Der Compiler erzeugt seitdem immer extra-Prüfungen – auch in modernen Programmen, in denen new niemals nullptr zurückgibt. Wird /Zc:throwingNew gesetzt, entfällt das und das Programm wird ein kleines Bisschen schneller und kleiner.

Ich nutze eh kein new, darum mir auch dieser Schalter nichts gebracht.

Wieder eine neue Linker-Option gegen Bloat: /nocoffgrpinfo. Entfernt 100–500 B readonly-Daten (je nach Umfang des Programms). Nur nutzen, falls ihr kein PGO einsetzt.

Erklärung: Ca. 2015 hat Visual Studio angefangen, einen Verweis auf die PGO-Datenbank in die Executable einzubetten. Die wird wohl für die Datensammlung bei Profile-Guided-Optimization benötigt. Das Ding ist, dass Visual C++ diesen Verweis in die Executable einbettet, sogar wenn PGO deaktiviert ist. Fragt mich nicht, warum.

Den PGO-Verweis erkennt ihr an Strings in der Executable, die nach Section Identifiers aussehen – etwa .text$mn oder .rdata$zzzdbg. Virustotal listet das mitunter als Debug-Information auf.

/nocoffgrpinfo hält den Linker davon ab, diese Daten einzubetten.

Manchmal ist auch /Bd hilfreich, das zeigt an mit welchen Optionen der cl1 und cl2 intern aufgerufen wird, inklusive der vordefinierten Makros.

Die Option /Bt zeigt an, wie lange das Kompilieren dauert.

Option /Bv gibt die Pfade und Versionen der vom Compiler verwendeten Dlls an.

Bei hartnäckigen Fehlern im Zusammenhang mit Makros hilft /E, das gibt die Ausgabe vom Preprozessor nach stdout.

Die Option /stdIncludes zeigt die inkludierten Files mit absolutem Pfad an.

Die Option /link /verbose:lib zeigt die Libs an, mit denen der Linker arbeitet.

Die Option /Zl unterbindet meistens das Einfügen von Linker Direktiven in das Object File.
Das ist nützlich, wenn man nicht mit den Standard-DLLs der verwendeten VS Installation linken möchte.

Bei hartnäckigen Fällen hilft auch die Linker Option /nod, die die Default Libs ignoriert.

Für deterministische Builds ohne Timestamp hilft /brepro

Oh ja, /Zl verwende ich auch oft, wenn die Codebase bezüglich der Bibliotheken nur Wildwuchs hat!