Ich habe ein Projekt, das innerhalb von g ++ kompiliert wurde (ich kann die Version gerade nicht sehen) und jetzt auf xCode ist es nicht.
Ich denke, dass ich das Problem jetzt habe ... Ich habe eine String.h-Datei in meinem Projekt und es scheint, dass der xCode-Compiler (das ist gcc) versucht, meine eigene String-Datei aus dem & lt; cstring & gt; ... Ich bin mir nicht sicher, aber sehen Sie sich dieses Bild an Ссылка
von dem, wie es aussieht, es ist meine eigene anstelle der Systemdatei, ich frage mich ... sollte nicht # enthalten & lt; Datei & gt; ein System sein? wegen der & lt; & gt; ? und sollte das System keine Datei in seinem eigenen Pfad enthalten und nicht den ursprünglichen Pfad meiner Anwendung?
Wie gesagt, ich bin mir nicht sicher, ob das passiert, weil ich gerade in den letzten 2 Tagen zu osx migriere ...
Ich würde meinen Klassen- und Dateinamen ändern, um Konflikte zu vermeiden, also würde es funktionieren, wenn das wirklich das Problem ist, aber ich frage mich, es sollte einen anderen Weg geben, dies zu tun, weil mein Projekt jetzt nicht so groß ist Ich kann das irgendwann, aber was wäre, wenn das Projekt größer wäre? Es wäre schwierig, alle Includes und Klassennamen zu ändern ...
Jede Hilfe ist willkommen
Danke,
Jonathan
Benennen Sie Ihre Header mit dem gleichen Namen wie Standard-Header wie string.h und fügen Sie sie einfach mit #include <String.h> ein, um Ärger zu vermeiden (der Unterschied in der Hülle macht auf manchen Plattformen keinen Unterschied).
Wie Sie jedoch schon gesagt haben, wäre es schwierig, herauszufinden, was diese im Voraus sind, wenn Sie Ihre Kopfzeilen benennen. Daher ist der einfachste Weg dies zu tun, indem Sie Ihren Include-Pfad auf eine Verzeichnisebene außerhalb eines Unterverzeichnisses setzen, in dem sich Ihre Header befinden, zB:
%Vor% Jetzt müssen Sie sich keine Gedanken darüber machen, ob der String.h-Dateiname mit einem der Bibliotheken kollidiert, die Sie verwenden, es sei denn, sie enthalten auch <Jonathan/String.h> , was unwahrscheinlich ist. Alle anständigen Bibliotheken von Drittanbietern tun dies auch. Wir fügen zum Beispiel <function.hpp> nicht in Boost ein, sondern fügen stattdessen <boost/function.hpp> hinzu. Das Gleiche gilt für GL / GL.h anstelle von einfach GL.h. Diese Praxis vermeidet Konflikte zum größten Teil und Sie müssen Probleme nicht umgehen, indem Sie String.h in etwas wie Text.h umbenennen.
Ich hatte das gleiche Problem und es war schwer zu lösen. brauchte meine Stunden um zu reparieren. Das Problem ist die Headerkarte von xcode. und die Lösung - neben der Vermeidung dieser Art von reservierten Namen, was im Allgemeinen eine gute Idee ist, aber nicht immer mit Third-Party-Bibliotheken möglich ist - ist das Hinzufügen von
%Vor%zu Ihren benutzerdefinierten Einstellungen.
Ja, wenn Sie
verwenden %Vor%Das lokale Verzeichnis wird zuerst gesucht und
%Vor%Nur das System enthält Ordner.
Beachten Sie das Wort zuerst nur im ersten Fall. Das bedeutet, dass jedes Mal, wenn die Zeit eingeschlossen ist, Ihre lokale Version niemals erreicht werden sollte (, es sei denn, Sie haben Ihren Quellpfad in die INCLUDE-Direktive aufgenommen).
Gesagt, mein Pseudovorschlag ist, Ihre lokale Datei mit einem eindeutigen Namen umzubenennen ...
funktionierte, indem der Name von String.h in Text.h geändert wurde
aber das macht keinen Sinn, da die std-Bibliothek ihre eigene string.h und nicht meine enthält.
Ich meine, es macht keinen Sinn für einen Entwickler, seine Dateien zu erstellen, indem er daran denkt, welche Namen er nicht verwenden kann. Nehmen wir an, ich ändere meine String.h zu Text.h (das habe ich bereits getan, ich muss arbeiten und das mich nicht lassen) ad irgendwie musste ich eine andere gestempelte Bibliothek einschließen, die ein Einschließen hat, das Text.h genannt wird, würde ich meinen text.h wieder ändern oder diese neue Bibliothek nicht verwenden müssen? es sollte eine Alternative geben.
Oder sollte es nicht?
danke für die Hilfe bis jetzt,
Jonathan
Zwei Dinge, auf die Sie stoßen:
Die Problemumgehung, die ich vorschlage, anstatt Ihre Includes umzubenennen, besteht darin, Ihre Dienstprogramme in ein Verzeichnis zu stellen, dessen Name für Ihr Projekt eindeutig ist, und dieses Verzeichnis in Ihrer include-Direktive anzugeben. Zum Beispiel:
%Vor% und stellen Sie sicher, dass sich Josk/ selbst nicht in Ihrem Include-Suchpfad befindet. Auf diese Weise bleiben Sie nicht beim umständlichen Umbenennen hängen, obwohl Sie möglicherweise einige Dateien in Ihrem Projekt mischen müssen. Sie müssen möglicherweise auch Ihre Projekteinstellungen bearbeiten, um sicherzustellen, dass das übergeordnete Verzeichnis dieses Dienstprogrammverzeichnisses in Ihrem Include-Pfad enthalten ist.
Sie können auch versuchen, das Projektverzeichnis der obersten Ebene, das dem Include-Pfad Ihres Projekts hinzugefügt wurde, zu entfernen. Dies sollte verhindern, dass Elemente in Ihrem Top-Level-Projektverzeichnis nach System-Includes durchsucht werden.
Schließlich können Sie dieses Problem möglicherweise auch in diesem speziellen Fall vermeiden, indem Sie die Groß- und Kleinschreibung Ihres Dateisystems ändern. Dies kann jedoch einige Mac-Anwendungen kaputt machen, also recherchieren Sie das Problem, bevor Sie damit beginnen - oder wählen Sie ein Volume, das sonst nichts verwendet.
