"error LNK2005: already defined" trotz Mehrfach-Include-Sperre?
-
Tachyon schrieb:
Bashar schrieb:
Eine globale Konstante wie hier das COLOR_FRIEND zu adressieren kostet auch jedesmal einen vollen Pointer, also kommst du damit speichertechnich nicht besser weg. Dazu kommt der Performanceverlust durch den Speicherzugriff.
Ja, das ist ganz bestimmt praxisrelevent, und ein Grund, Konstanten zu vermeiden.
Ja. Nein. Weil sie in der Regel wegoptimiert werden. BTW wirkt das Augenrollen in deiner Position nicht so, wie du dir das vielleicht erhoffst.
-
Tachyon schrieb:
Btw. kommt in der Realität das Gleiche raus, egal wie man es macht.
Ohne Optimierung nicht...
-
EOutOfResources schrieb:
Tachyon schrieb:
Btw. kommt in der Realität das Gleiche raus, egal wie man es macht.
Ohne Optimierung nicht...
Ohne Optimierung ist es (hoffentlich) kein produktiver Code. Dann macht der Unterschied vom Speicherverbrauch auch nichts aus.
-
pumuckl schrieb:
Ohne Optimierung ist es (hoffentlich) kein produktiver Code.
Schön wärs
Ich hab schon relativ häufig gehört, dass Leute unoptimierten Code ausliefern. Angeblich, weil sie Angst haben, der Optimierer könnte Fehler haben. Das ist natürlich vorgeschoben.
-
Bashar schrieb:
pumuckl schrieb:
Ohne Optimierung ist es (hoffentlich) kein produktiver Code.
Schön wärs
Ich hab schon relativ häufig gehört, dass Leute unoptimierten Code ausliefern. Angeblich, weil sie Angst haben, der Optimierer könnte Fehler haben. Das ist natürlich vorgeschoben.Ist mein Windows deshalb manchmal so lahm?
-
EOutOfResources schrieb:
C++-Code gehört in .cpp- und in .hpp-Dateien! Können wir das mal in die FAQ bringen?Wie kommst du auf die Idee, dass .h so falsch ist?
Durchaus gängige Praxis.
-
Bashar schrieb:
Schön wärs
Ich hab schon relativ häufig gehört, dass Leute unoptimierten Code ausliefern. Angeblich, weil sie Angst haben, der Optimierer könnte Fehler haben. Das ist natürlich vorgeschoben.Nicht ganz, wenn es auch nicht aktuelle Compiler betreffen sollte... Es gibt Firmen die schon lange nicht mehr supportete Entwicklungsumgebungen einsetzen, wo der Optimierer tatsächlich die Ausführreihenfolge in Verherrender Weise geändert hat.
Natürlich ist es in gewisser Weise Schuld der Firma, wenn sie auf ein "toten Pferd" sitzen bleiben...
Das ist aber die einzige Situation wo ich von so einem Fehler weiß, und auch einen solchen Fehler bestätigen kann.
-
Weißt du da was konkretes? Compilerfehler sind ziemlich übel, und eigentlich dürfte man einen Compiler gar nicht verwenden, der sich sowas leistet. Die meisten vermeintlichen Optimierungsfehler dürften darauf zurückgehen, dass da jemand undefiniertes Verhalten auslöst.
-
Bashar schrieb:
Weißt du da was konkretes? Compilerfehler sind ziemlich übel, und eigentlich dürfte man einen Compiler gar nicht verwenden, der sich sowas leistet. Die meisten vermeintlichen Optimierungsfehler dürften darauf zurückgehen, dass da jemand undefiniertes Verhalten auslöst.
Ist schon etwas her, betraf Power++ 2.5 (Leider weiß ich den genauen Fall nicht mehr, ist schon ein paar Jahre her, und ich habe zum Glück nichts mehr mit der Umgebung zu tun).
-
Meines Wissens können selbst aktuelle optimierer "korrekten" code kaputt machen, selbst die CPU-Interne Branch prediction kann eigentlich funktionierenden code - meines Wissens - in einer Multithreaded Umgebung ruinieren (bzw race conditions schaffen wo vorher keine waren). Stichwort "Optimistic write". Bin mir aber nicht sicher ob euch sowas sowieso klar ist, und ihr seht eine fehlende Verwendung der entsprechenden keywords/methoden, die das unterbinden bereits als falschen code an - dann will ich nix gesagt haben.