"error LNK2005: already defined" trotz Mehrfach-Include-Sperre?

[Bashar]

Tachyon schrieb:

Bashar schrieb:

...In dem Fall liegt die 42 direkt im Code, sie wird nicht adressiert...

Und weils ein RValue ist belegt es keinen Speicher?

Doch, aber das ist mit der Aussage gemeint.

Ich meinte schon, was ich sage. Wenn der Compiler das so wie Du hier zeigst optimieren würde, dann wäre das sogar ziemlich bescheinden, weil dann an jeder Stelle an der die Konstante benutzt wird ein neues Literal im Code stehen würde. Da braucht dann quase Speicher im Quadrat.

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.

[Tachyon]

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.
Btw. kommt in der Realität das Gleiche raus, egal wie man es macht.

[Bashar]

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.

[EOutOfResources]

Tachyon schrieb:

Btw. kommt in der Realität das Gleiche raus, egal wie man es macht.

Ohne Optimierung nicht...

[pumuckl]

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.

[Bashar]

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.

[_matze]

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?

[Ethon]

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.

[asc]

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.

[Bashar]

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.

[asc]

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).

[kleiner Troll]

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.