Darf Compiler member entfernen?
-
Yes, no, is clear.
-
Warum muß dazu erst die Adresse eines Members benutzt werden? Man könnte auch einfach den gesamten Speicher auslesen (wenn man vorher bestimmte Werte den einzelnen Membern zugewiesen hat)..
-
@swordfish sagte in Darf Compiler member entfernen?:
Um das beobachten zu können müsste ein Programm erst einmal die Adressen von zwei Membern nehmen. Dazu müssen die Dinger dann auf jeden Fall existieren.
Ja, aber das kriegt der Compiler von Programm A nicht mit, wenn Programm B (auf welche Art auch immer) den Speicher von A ausliest.
-
@th69 könnte klappen:
struct test {char c1; char c2; char c3;}; struct test t; t.c1 = 1; t.c3 = 2; char *p = (char*)&t; printf ("%d, %d, %d\n", p[0], p[1], p[2]);
Kommt 1,irgendwas,2, wurde c2 nicht wegoptimiert.
kommt 1,2,irgendwas, ist c2 nicht da.
-
@happystudent sagte in Darf Compiler member entfernen?:
Ja, aber das kriegt der Compiler von Programm A nicht mit, wenn Programm B (auf welche Art auch immer) den Speicher von A ausliest.
Das hat nichts mehr mit dem Standard zu tun.
-
@th69 sagte in Darf Compiler member entfernen?:
Warum muß dazu erst die Adresse eines Members benutzt werden? Man könnte auch einfach den gesamten Speicher auslesen (wenn man vorher bestimmte Werte den einzelnen Membern zugewiesen hat).
Dazu müssen die Member sowieso existieren also im Kontext der Fragestellung in diesem Thread ein no brainer.
-
@regenbogenschaf sagte in Darf Compiler member entfernen?:
@th69 könnte klappen:
struct test {char c1; char c2; char c3;}; struct test t; t.c1 = 1; t.c3 = 2; char *p = (char*)&t; printf ("%d, %d, %d\n", p[0], p[1], p[2]);
Kommt 1,irgendwas,2, wurde c2 nicht wegoptimiert.
kommt 1,2,irgendwas, ist c2 nicht da.Kommt ... undefined behaviour.Ne, sorry, nicht ub. Aber es können trotzdem padding-bytes sein.
-
@swordfish sagte in Darf Compiler member entfernen?:
Kommt ... undefined behaviour.
Ja, und allein schon die Adresse von t zu nehmen, dürfte den Compiler dazu bringen, den unbenutzten Member nicht wegzuoptimieren.
-
Was soll der quatsch? Die Frage war, ob ein Compiler es darf. Die Antwort ist auch klar: Ja, er darf, wenn sich dadurch das beobachtbare Verhalten des Programms nicht ändert.
-
@swordfish sagte in Darf Compiler member entfernen?:
Aber es können trotzdem padding-bytes sein.
Dann nehme man 3 int, dann dürfte er IMHO nur hinten auffüllen, bis die Länge ein Vielfaches von 4 ist.
-
@swordfish sagte in Darf Compiler member entfernen?:
Die Frage war, ob ein Compiler es darf. Die Antwort ist auch klar: Ja, er darf, wenn sich dadurch das beobachtbare Verhalten des Programms nicht ändert.
Das Verhalten würde sich vielleicht schon durch die Messung ändern. Heisenberg lässt grüßen.
-
was willst du da messen?
-
@swordfish sagte in Darf Compiler member entfernen?:
was willst du da messen?
Physikalisches Vorhandensein unbenutzter Struct-Members.
-
Sag mal, was hast du an "as-if" nicht verstanden? Du wirst es innerhalb des Programms (die Sprachmittel von C++ benutzend) nie feststellen können, weil entweder der Compiler Dir vorgaukelt, wegoptimierte Member wären da oder Du ihn durch Deine "Messung" dazu zwingst, sie tatsächlich irgendwo im Speicher zu haben.
-
@swordfish sagte in Darf Compiler member entfernen?:
Du wirst es innerhalb des Programms (die Sprachmittel von C++ benutzend) nie feststellen können, weil entweder der Compiler Dir vorgaukelt, wegoptimierte Member wären da oder Du ihn durch Deine "Messung" dazu zwingst, sie tatsächlich irgendwo im Speicher zu haben.
Das ist ja das, worüber wir uns hier unterhalten. Bleibt wohl nur noch, den erzeugten Maschinencode anzugucken.
-
@regenbogenschaf sagte in Darf Compiler member entfernen?:
Bleibt wohl nur noch, den erzeugten Maschinencode anzugucken.
Von etwas anderem bin ich, da es um Optimierung geht, auch nie ausgegangen.
-
@happystudent sagte in Darf Compiler member entfernen?:
@hustbaer Ist das also nur bei calls von "für den Compiler nicht sichtbaren" Code garantiert?
Ich könnte jetzt einfach "ja" sagen, aber ich glaube das würde dich bloss noch mehr verwirren.
-
Wenn man das gesamte Programm betrachtet, dann darf der Compiler tatsaechlich Member wegoptimieren, weil kein neuer Code mehr darauf zugreifen kann, und der gegebene Code nicht davon abhaengig sein muss. Letzteres zu beweisen ist allerdings nicht traktabel. Bspw. wuerden durch die Entfernung eines Members gewisse Ungleichungen der Adressen von Membern nicht mehr gelten (obwohl ich mir in dem Fall nicht sicher bin, welche Garantien der Standard macht).
Um Schnittstellen solltest du dir keine Sorgen machen: Das kompilieren einer individuellen TU muss eine Objektdatei erzeugen, die mit jedem anderen Kompilat kompatibel sein muss. Im Grunde musst du dir sowieso keine Sorgen machen, weil der Compiler nur Transformationen durchfuehrt, die nachweislich nicht observiert werden koennen.