//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?

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

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)

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

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.

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