Künstliche Bereiche schaffen für Destruktoraufruf

5cript

Ich habe folgendes Szenario:

//Hier ist was
{
	DWORD buffer = 0; // Variable für die Schleife
	for (DWORD i = 0; i < 10; i++)
	{
		// something
	}
}
//Hier gehts weiter

Ich habe hier nun künstlich einen Bereich um den buffer und die Schleife geschaffen um den Gültigkeitsbereich einzuschränken, damit ich buffer nicht mitschleppe.

1. Ist das Designmist?
2. Wird buffer auch wirklich nach der letzten Klammer zerstört?

*Q* 1

1. Meiner meinung nach ist das kein designmist
2. ja, aber bei einem DWORD gibt es nicht besonders viel zu zerstören

314159265358979

Dein ganzes Programm ist künstlich.

XSpille

Tim06TR schrieb:

1. Ist das Designmist?

Da es nur ein DWORD ist, imo ja.
An sowas könnte man nur bei großen Puffern denken
Aber in der Regel kann man den Puffer ja auch manuell leeren.

Ein Beispiel, wo ich schonmal einen zusätzlichen Scope verwende, ist beim Sperren eines Mutexes, damit er nicht länger als nötig gesperrt bleibt.

Tim06TR schrieb:

2. Wird buffer auch wirklich nach der letzten Klammer zerstört?

Ja

volkard

Ich mach's mit fstreams.

Martin Richter

zu 2.
Das verkleinert aber nicht unbedingt den genutzen Stack. Wenn man also einen "großes" Objekt auf dem Stack hat (char array etc.) dann wird der benötigte bei den meisten Compilern allokiert wenn die Funktion betreten wird und nicht erst dieser Block...

pumuckl

Tim06TR schrieb:

1. Ist das Designmist?

Vom Design her unnötig. Du führst hier künstliche Scopegrenzen ein, die aber im Programm an sich keinen Unterschied machen. Soll heißen, das Ergebnis ist mit und ohne die Klammern das selbe. Aus Performance-Sicht könnte es einen Unterschied machen, ich bezweifle das aber. Mir ist kein Compiler bekannt, der wegen ein paar Bytes mitten in der Funktion plötzlich Teile des Stacks wieder freigibt.
Zusammengefasst: Designmist auf jeden Fall. Premature-Optimization-Mist auch, soweit du nicht nachgewiesen hast, dass das eine DWORD kriegsentscheidend ist und der Compiler da wirklich auch was ändert, wenn du den künstlichen Scope einführst.

2. Wird buffer auch wirklich nach der letzten Klammer zerstört?

Nein. Du hast keinen Zugriff mehr, weil der Compiler dich nicht lässt, d.h. der buffer ist rein syntaktisch aus dem Scope gelaufen. Zerstört wird garnichts, da dein DWORD ein POD ist und faktisch keinen Destruktor besitzt. Soll heißen, es gibt nichts zu zerstören. Die Variable läuft einfach aus dem Scope, ohne dass irgendwas passiert. Irgendwann wird der Speicher auf dem Stack wieder freigegeben, aber das ist eine andere Abstraktionsebene als die Zerstörung eines Objektes. Und wann das ist, liegt beim Compiler, auch ob der Compiler sich diesbezüglich um die Klammern schert. (Siehe oben)

*Q* 1

Ich hatte angenommen, das das DWORD nur als Platzhalter für eine möglicherweise teure Klasse steht, die evtl. sogar andere ressourcen außer speicher hält.

Steht das DWORD bei dir wirklich nur für ein DWORD?

hustbaer

Das ist kein Designmist, da es mit Design nix zu tun hat.

Da es sich um ein DWORD handelt, ist es auch vollkommen sinnbefreit - und ist mMn. daher als Mist einzustufen.

Sollte es mal was sein, wo die frühere Zerstörung wirklich Sinn macht ... naja, dann macht es halt Sinn, und ist daher auch kein Mist mehr.

5cript

DWORD war nur ein Beispiel.
An Handles habe ich gar nicht gedacht,
aber dort könnte ja auch ein smartpointer stehen.

Skym0sh0

Tim06TR schrieb:

DWORD war nur ein Beispiel.
An Handles habe ich gar nicht gedacht,
aber dort könnte ja auch ein smartpointer stehen.

lass mal

ist ja nicht so als sei das das erste mal gesagt. manche leute sind hier manchmal etwas ignorant was sowas angeht. da sind das richtige erbsenzähler...

klar macht das für einen scheiss build in type keine unterschiede, aber für komplexe datentypen wäre es schon recht hilfreich zu wissen was passiert und auch dementsprechend sinnvoll das anzuwenden