Ich bin gerade auf eine Visual C ++ - Option gestoßen, mit der Sie Dateien erzwingen können - dies kam zustande, als ich Code suchte, dem in jeder CPP-Datei ein #include "StdAfx.h" fehlte, aber es war dies tatsächlich über diese Option tun.
Die Option befindet sich auf der Seite Erweiterte C / C ++ - Konfigurationseigenschaften und entspricht der Compileroption / FI .
Diese Option könnte sich als sehr nützlich erweisen, aber bevor ich losfahre und anfange, sie zu benutzen, dachte ich, ich würde fragen, ob es irgendwelche Probleme gibt?
Ich würde von / FI abraten ( MSDN sagt, es heißt / FI. Nicht sicher, ob Ich habe aber die richtige Seite angeschaut), einfach weil die Leute oder die Leute, die die Dateien lesen, nicht bemerken, dass eine Kopfzeile sowieso magisch enthalten ist.
Sie können sicher sein, dass dies viel Zeit für die Fehlersuche verursacht, wenn jemand herausfinden will, woher bestimmte Makros kommen, obwohl keine #include -Zeilen am Anfang der Datei stehen.
Ich würde das Gegenteil von Litb oben sagen, wenn Sie vorkompilierte Header verwenden. Wenn Sie "stdafx.h" als vorkompilierten Header verwenden und Code wie folgt haben:
%Vor%dann werden Sie ein Alter verbringen, um herauszufinden, warum "afile.h" nicht enthalten ist. Bei Verwendung vorkompilierter Header werden alle Includes und #defines bis "stdafx.h" ignoriert. Also, wenn Sie zwingen, die "stdafx.h", dann wird das oben genannte nie passieren und Sie werden ein Projekt, das die vorkompilierte Option effizient verwendet.
Wie bei Litb's Kommentar über das Finden von Makros, haben gute IDEs normalerweise eine Option, um zu der Definition eines Symbols zu springen, egal ob es sich um #define, eine Funktion, eine Klasse usw. handelt.
Ich würde auf der Seite von litb stehen: Mach nicht die erzwungenen Includes. Wenn der Code explizit ist, ist es einfacher zu wissen, was für einen neuen Benutzer vor sich geht. Es macht es auch einfacher zu wissen, was passiert, wenn Sie den Code auf eine neue Plattform portieren müssen.
Beachten Sie, dass Visual Studio die Definitionen normalerweise nicht korrekt aufspüren kann, wenn der Code Vorlagen verwendet. Vielleicht wird 2010 besser, aber auch VS 2008 ist in dieser Hinsicht problematisch.
Force includes ist auch hilfreich für automatisch generierte Quelldateien. Unser System verwendet ein Tool, das viele Quelldateien generiert, aber nicht unsere vorkompilierte Header-Datei. Mit "force includes" ist das Kompilieren dieser Dateien jetzt schneller.
Optional wäre es möglich, ein Skript zu schreiben, um nach der Generierung und vor der Kompilierung die # include-Zeile in diese Dateien einzufügen. Aber warum zu diesen Schwierigkeiten gehen?
Ich würde es nicht so oft benutzen, aber es hat seinen Nutzen. Ich habe es verwendet, um eine Kopfzeile hinzuzufügen, die einige Warnungen für alle cpp-Dateien unterdrückt, so dass ich / W4 oder / Wall für das Projekt aktivieren konnte und nicht alle cpp-Dateien bearbeiten musste, um zuerst den Header der Warnungsunterdrückung aufzunehmen. Sobald alles funktionierte, ging ich zurück und bearbeitete alle cpp-Dateien, aber für einen Proof of Concept / FI war nützlich.
Ebenso können Sie einen vorkompilierten Header in einigen Build-Konfigurationen in cpp-Dateien erzwingen, aber nicht in allen Fällen (falls Sie eine Build-Konfiguration haben möchten, die vorkompilierte Header verwendet und sicherstellt, dass jedes cpp nur genau was enthält) es muss). Allerdings ist die Verwendung von #pragma hdrstop, IMHO, ein besserer Weg, dies zu erreichen.
Ich habe über all das in meinem Blog hier gesprochen: Ссылка in ein wenig mehr Detail.
Tags und Links c++ visual-c++