Benennung von "Accessors"

[Gast]

@Dravere, ohne wirklich richtig zu cheaten (weil es sozusagen wirklich stimmt) könnte man den Byteoffset des Member-Accessors mitgeben, dann kann der sich aus seinem eigenen this-Zeiger den des umliegenden Objekts errechnen. Fällt mir gerade so ein. Ist natürlich unschön, aber sieht nachher niemand mehr^^
Edit: Vielleicht würde ein guter Compiler dann ach die Ausdrücke x+offset-offset erkennen, die da dann immer auftauchen und sie gleich ganz eliminieren...

[Gast]

Nexus schrieb:

Zu den Accessor -spezifischen Dingen: Ich hab mir da keine konkrete Implementierung gebastelt, das sind mehr ein paar Vorstellungen. Mit den impliziten Konvertierungen habe ich gemeint, dass sie dann erwünscht sind, wenn die Property von ausserhalb der Klasse benutzt wird (als Getter), und dann sollen sie immer in Kraft treten. Jedoch ist das manchmal schwierig:

template <typename T>
void DoSomething(T t);

DoSomething(obj.Size);
// Da der erste Parameter ein Template-Typ-Parameter ist, wird nie eine
// Konvertierung vorgenommen. Man übergibt also das Proxy statt der Grösse

Da hast du natürlich recht, das würde zu vielen unnötigen Template-Instanziierungen führen. Grumpf.
Edit: Snip. Stimmt natürlich gar nicht, es kann ja in der Form keine freien Instanzen von den Accessor-Objekten geben, aber dein Beispiel gilt natürlich analog für Referenzen.

[Bashar]

Nexus schrieb:

Dem entnehme ich, dass die Optimierung in den anderen Fällen streng genommen nicht erlaubt ist, auch wenn keine Seiteneffekte vorhanden sind.

Doch, Optimierungen sind immer erlaubt. Die einzige Forderung ist, dass das Programm sich nach außen hin so verhält, wie es spezifiziert ist. Die Sonderregel mit dem Kopierkonstruktor besagt, dass in gewissen, genau festgelegten Fällen Kopierkonstruktoren wegoptimiert werden dürfen, selbst wenn sich dadurch Änderungen im beobachtbaren Verhalten ergeben.

[Nexus]

So macht das natürlich Sinn. Danke für die Erklärung!

[Dravere]

Decimad schrieb:

@Dravere, ohne wirklich richtig zu cheaten (weil es sozusagen wirklich stimmt) könnte man den Byteoffset des Member-Accessors mitgeben, dann kann der sich aus seinem eigenen this-Zeiger den des umliegenden Objekts errechnen. Fällt mir gerade so ein. Ist natürlich unschön, aber sieht nachher niemand mehr^^
Edit: Vielleicht würde ein guter Compiler dann ach die Ausdrücke x+offset-offset erkennen, die da dann immer auftauchen und sie gleich ganz eliminieren...

Meinst du dies jetzt als Lösung wegen dem Problem mit this ? Dann ist deine Idee alles andere als sinnvoll. Das Programm greift schliesslich selber bereits genau so drauf zu. Da ändert es nichts, ob man nun selber über den Offset geht oder der Kompiler dies über this für einem ausrechnet. Es bleibt undefiniertes Verhalten.
Eine Möglichkeit, was passieren könnte, ist, dass du über den Offset die Speicherstelle beschreibst, da die Klasse aber noch nicht vollständig initialisiert ist, wird der Speicherbereich dann vom eigentlichen Konstruktor erneut überschrieben und deine Initialisierung geht flöte.

Definitiv keine gute Idee ...

@Nexus,
Deswegen können eben C und C++ Kompiler so aggressiv optimieren, weil es grundsätzlich keine Verbote gibt. Und die Regel ist eben nur eine Hilfe für zusätzliche Optimierungen. C++ ist voll darauf ausgelegt, dass optimiert werden kann ohne Ende.

Grüssli

[Gast]

@Dravere, du hast mich offenbar missverstanden. Ich wollte damit nicht das "zu frühe" Verwenden von "this" umgehen, sondern den Speicherplatz für this_ im Accessor einsparen (womit sich auch komplett die zu frühe Benutzung erübrigt, weil der Accessor nicht mehr die Laufzeit-Hilfe der beinhaltenden Klasse benötigt).

[Nexus]

Eigentlich war mir diese Grundsatzregel mit dem Optimieren bekannt, doch da der Standard sich im Bezug auf Kopierkonstruktoren so explizit ausdrückte, hielt ich das für bindend. Von der Grundsatzregel habe ich hingegen nie was Offizielles gelesen...

Abgesehen davon weiss ich nicht, wie offensiv heutige Compiler sind. Aber auf die "guten" Klassen von dazulerner wird es wohl schon zutreffen. Dennoch wäre ich vorsichtig mit dem Spekulieren auf Kopier-Optimierungen, sobald der Einfluss auf die Performance wesentlich wird.

[Dravere]

Decimad schrieb:

@Dravere, du hast mich offenbar missverstanden. Ich wollte damit nicht das "zu frühe" Verwenden von "this" umgehen, sondern den Speicherplatz für this_ im Accessor einsparen (womit sich auch komplett die zu frühe Benutzung erübrigt, weil der Accessor nicht mehr die Laufzeit-Hilfe der beinhaltenden Klasse benötigt).

Kannst du mir das zeigen, wie du das machen willst?
Ich zweifle sehr, dass du dies definiert hinbekommst.

Nexus schrieb:

Dennoch wäre ich vorsichtig mit dem Spekulieren auf Kopier-Optimierungen, sobald der Einfluss auf die Performance wesentlich wird.

Da stimme ich dir zu.

Grüssli

[Gast]

Leider gar nicht, aber im Prinzip wüsste der Compiler es ja, schade nur, dass er es uns für nicht POD-Klassen nicht sagen mag.
Also bei konformer C++-Benutzung ist man auf diesen this_-Zeiger angewiesen.
Aber ich meine in Boost sogar schonmal solche nicht-Standardkonformen Pro-Compiler-Optimierungen gesehen zu haben.

[Bashar]

Nexus schrieb:

Eigentlich war mir diese Grundsatzregel mit dem Optimieren bekannt, doch da der Standard sich im Bezug auf Kopierkonstruktoren so explizit ausdrückte, hielt ich das für bindend. Von der Grundsatzregel habe ich hingegen nie was Offizielles gelesen...

1.9§5:
"A conforming implementation executing a well-formed program shall produce the same observable behavior as one of the possible execution sequences of the corresponding instance of the abstract machine with the same program and the same input. [...]"

Fußnote: "This provision is sometimes called the «as-if» rule, because an implementation is free to disregard any requirement of this International Standard as long as the result is as if the requirement had been obeyed, as far as can be determined from the observable behavior of the program. [...]"

[Nexus]

Ah, alles klar. Danke.