C++ Paar fragen zu c++

[abdi-61]

Hi,

hätte paar fragen zu c++

1. Ist es möglich die geschweiften klammern selber zuzuweisen ?
denn ich will z.b ne do -while schleife machen aber das "do"
wählt immer die falsche klammer.

2.kann man bei c++ bei der konsole eine teil konstant einen satz anzeigen lassen z.b
skizze:

|-----------------------------------------------|
| Hier soll ein satzt permanent stehen|
|_____________________________|
|hier macht das programm normal |
| weiter. |

3.kann man bei c++ zeilen springen ?
also z.b
if(x == 1)
{
go to zeile 20;
}

oder so ähnlich ^^

danke schonmal

ps: ich nutze visual studio 2010

 

[the_nobs]

Es gibt goto in C und C++
Aber zur dunklen Seite der Macht es dich führt junger Padawan :-)

Warum brauchst du ein Goto? mit ein bischen hirn sollte sich das ja so auch lösen lassen

 

[yoT!mO]

Zu 1.: Kapier nicht, was du meinst.
zu 2.: es gibt die Möglichkeit, Zeilen zu überschreiben und den Cursor weiter nach oben zu setzen. Damit kannst du den gewünschten Effekt erzielen. Das ist aber plattformspezifisch, da musste halt mal googlen.
zu 3.: Geht, ist aber sehr schlechter Stil. Man nimmt stattdessen lieber Schleifen.

Gruß Timo

 

[Fidikus]

Zu 1.) Ich verstehe dein Problem nicht so ganz. Der C++ Compiler wählt keine Klammer, sondern du setzt die Klammer falsch. Der Compiler ist kein Germanistiker, der deinen Sourcecode frei nach Schnauze interpretiert, sondern ein deterministisch arbeitendes Programm... Die Klammern geben dem Compiler klare Anweisungen!

Zu 2.) Ja

Zu 3.) goto gibt es weiterhin, allerdings nicht mit Zeilen, sondern mit einem Label. Stelle dir vor du hättest Zeilen, und fügst dazwischen was ein, dann müsstest du alle Zeilen korrigieren. Goto nutzt man aber generell nicht, es ist einfach Spaghetti-Programmierung

 

[mvBarracuda]

1. Huh?

2. Ja. Einfach einen Header definieren, und dann diesen bei jeder neuen Ausgabe mit ausgeben lassen, anschließen den Bildschirminhalt clearen.

3. Lesen und verstehen: http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html

 

[abdi-61]

ok zu 1 will ich dan ein beispiel geben

das ist ein teil von meinem programm

system("CLS");
cout<<"Gib die 1. Zahl ein: \t";
cin>>x;

for(a=2; a<100000; a++)
{
cout<<"Gib die "<<a<<". Zahl ein: \t";
cin>>eingabe;

if (eingabe == "end")
{
break;
}

else
{
stringstream wert;
wert<<eingabe;
wert>>y;
}

erg = x+=y;

cout<<endl<<"Das Ergebnis lautet \t"<<erg<<endl;


}

so funktioniert es auch, nun möchte aber einer do -while schleife einbauen damit ich bei wunsch zurück zum anfang des programmes komme.

also mach ich das

do
{
system("CLS");
cout<<"Gib die 1. Zahl ein: \t";
cin>>x;

for(a=2; a<100000; a++)
-> {
cout<<"Gib die "<<a<<". Zahl ein: \t";
cin>>eingabe;

if (eingabe == "end")
{
break;
}

-> }while (eingabe == new);
else
{
stringstream wert;
wert<<eingabe;
wert>>y;
}

erg = x+=y;

cout<<endl<<"Das Ergebnis lautet \t"<<erg<<endl;


}

doch statt do und while "verbindet sich die for schleife mit dem while, kann man die do- while schleife nicht überall setzten oder was mache ich falsch ?

die -> sind von mir jetzt eingefügt worden um zu zeigen welche klammern sich verbinden

 

[LeMumpelPumpel]

Du hast falsch geklammert. Das while ist ins else/if reingerutscht

 

[antred]

Steck deinen Code in Zukunft bitte in Code tags, nicht in Quote tags. Und vergiß am besten, daß goto überhaupt Bestandteil der Sprache C++ ist. Es gibt zwar einige, die behaupten, es gäbe ein paar wenige Situationen, in denen der Gebrauch von goto gerechtfertigt ist; ich selbst habe aber noch keine gesehen. Es gibt meiner Meinung nach immer eine bessere Lösung als goto.

 

[Dese]

zu 3.: Geht, ist aber sehr schlechter Stil. Man nimmt stattdessen lieber Schleifen.
Gruß Timo

in den meisten fällen stimmt das, sogar in den aller aller meisten. aber nicht immer.
es gibt situationen in denen ein goto den code deutlich einfach, überichtlicher und lesbarer macht als die alternativen komplizierten if-verschachtelungen.

man kann goto als eine art günstige lokale exception sehen. beispiel:

....
if( fehlerbedingung 1 ) {
    räume auf 1
    return 
}

...

if( fehlerbedingung 2 ) {
    räume auf 2
    return 
}

...

if( fehlerbedingung 3 ) {
    räume auf 1
    return 
}

eine alternative dazu wäre mit goto:

...
if( fehlerbedingung 1 ) {
   goto ende_1;
}

...

if( fehlerbedingung 2 ) {
   goto ende_2;
}

...

if( fehlerbedingung 3 ) {
   goto ende_1;
}

...

ende_2:
...

ende_1:

ich hab keine code-dublikation für "räume auf 1", weder bei fehler 1 und 3 noch bei fehler 2, wo "räume auf 1" bestandteil von "räume auf 2" ist.
ich muss auhc nur an einer stelle anpassungen machen, welche sich gleich auf alles auswirkt und vergesse somit nichts.

es gibt durch aus auch alternativen, aber jeh nach situation kann die goto variante immer noch die lesbarste und pflegeleichteste sein. ist mir zwar nur selten so passiert, aber es ist schon so gewesen.

 

[antred]

in den meisten fällen stimmt das, sogar in den aller aller meisten. aber nicht immer.
es gibt situationen in denen ein goto den code deutlich einfach, überichtlicher und lesbarer macht als die alternativen komplizierten if-verschachtelungen.

man kann goto als eine art günstige lokale exception sehen. beispiel:

Warum nicht einfach das ganze Zeug in eine separate Funktion auslagern, die dann in der ursprünglichen Funktion aufrufen und dann anschließend deine Aufräumarbeiten erledigen?

ODER

Warum nicht eine RAII_Guard-Klasse schreiben, in der Funktion eine Instanz lokal auf dem Stack erstellen und den Destruktor der Klasse die Aufräumarbeiten erledigen lassen.

Beides besser als goto.

 

[Dese]

Warum nicht einfach das ganze Zeug in eine separate Funktion auslagern, die dann in der ursprünglichen Funktion aufrufen und dann anschließend deine Aufräumarbeiten erledigen?

das geht, aber es kann mehrere gründe geben, die das unübersichtlicher oder gar inefizienter machen. bedenke es müssten hier zwei funktionen sein, wobei eine die anderen aufruft (verschachtelung der aufräum arbeiten).

jeh nach dem was da alles gemacht werden muss musst du evtl einiges parametriesieren. das macht es nciht unbedingt lesbarer.

sind deine funktionen inline, dann hast du ne code duplikation (die der compiler vor dir versteckt). beim goto hast du keine.

sind sie nicht inline, dann ist der aufruf der methoden teurer als das goto.

ODER

Warum nicht eine RAII_Guard-Klasse schreiben, in der Funktion eine Instanz lokal auf dem
Stack erstellen und den Destruktor der Klasse die Aufräumarbeiten erledigen lassen.

weil das wesentlich teurer ist. du hast ne klassen instanzierung, einen destructor-aufruf. die speicherdealokation fällt weg, da sie auf dem stack liegt.

aber du brauchst zwei klassen wegen der verschachtelung der aufräum arbeiten. damit hast du am ende mehr code und es wird unübersichtlicher als in der goto variante.

Beides besser als goto.

nö.

das goto hat keinen nachteil hier.

edit: mal anders rum gefragt: was stört dich hier an dem goto so sehr, dass du es so zwanghaft weg haben willst?

 

[antred]

weil das wesentlich teurer ist. du hast ne klassen instanzierung, einen destructor-aufruf. die speicherdealokation fällt weg, da sie auf dem stack liegt.

Mach dich nicht lächerlich. Die Laufzeitkosten werden absolut minimal ausfallen und wahrscheinlich nicht mal dann einen meßbaren Unterschied gebenüber der goto-Variante bewirken, wenn du tatsächlich zeitkritischen Code schreibst. Zusätzlicher Vorteil: du bist exception-safe -> deine Aufräumarbeiten werden sogar dann ausgeführt, wenn dein vorhergehender Code mit einer Exception rausflog. In der goto-Variante hättest du dazu extra noch mit try-catch rumhantieren müssen.

Ergänzung (8. November 2012)

edit: mal anders rum gefragt: was stört dich hier an dem goto so sehr, dass du es so zwanghaft weg haben willst?

Gute Frage. Eigentlich muß ich sogar zugeben, daß nicht so sehr meine Abneigung gegenüber goto als die Vorteile der RAII-Guard-Lösung für mich ausschlaggebend sind. Noch ein weiterer Vorteil ist dann nämlich, daß durch die Auslagerung der Aufräumarbeiten die Komplexität der ursprünglichen Funktion sinkt.

 

[Dese]

Mach dich nicht lächerlich.

also cih weiß ja nicht warum du so persönlcih werden musst, nur weil du offenbar eine erfahrungswelt hast, in der das keine rolle spielt.

Die Laufzeitkosten werden absolut minimal ausfallen und wahrscheinlich nicht mal dann einen meßbaren Unterschied gebenüber der goto-Variante bewirken, wenn du tatsächlich zeitkritischen Code schreibst.

was du glaubst ist davon abgesehen, dass es irrelevant ist, auch noch falsch!
wenn dieser funktion tausendfach un kurzer zeit aufgerufen wird, dann ist meine variante teils um faktor 10 oder gar mehr schneller als deine obigen varianten, ausser die inline variante mit den funktionen.
die bringen aber code-dupliklation mit.

Zusätzlicher Vorteil: du bist exception-safe -> deine Aufräumarbeiten werden sogar dann ausgeführt, wenn dein vorhergehender Code mit einer Exception rausflog. In der goto-Variante hättest du dazu extra noch mit try-catch rumhantieren müssen.

natürlich muss ich das mit try umklammern. und? inwiefern ist das ein nachteil?
muss man in deiner variante übrigens auch und deine aufräum-fuktionen bzw. klassen in den catch/final block setzten.

du schuldest mir immer noch die antwort, was dich an dem goto stört.

p.s. weil das ja so lächerlich ist wird goto ja auch so massenweise in z.b. kernel code verwendet, selbst in den c++ teilen.

Ergänzung (8. November 2012)

Gute Frage. Eigentlich muß ich sogar zugeben, daß nicht so sehr meine Abneigung gegenüber goto als die Vorteile der RAII-Guard-Lösung für mich ausschlaggebend sind.

welche vorteile? vieleciht hab ich ja deinen vorschlag mißverstanden.

Noch ein weiterer Vorteil ist dann nämlich, daß durch die Auslagerung der Aufräumarbeiten die Komplexität der ursprünglichen Funktion sinkt.

das geht in meiner variante genau so:
man nehme zwei inline-funktionen oder makros, aber sie werden nur an den goto marken aufgerufen.
damit ist keine code-duplikation aber der sichtbare code übersichtlicher.

ggf. ist eine inline funktion nicht möglich, dann gehts mit einem makro.

für deinen problemstellungen sind vieleciht diese performance aspekte (speicher und laufzeit) irrelevant. aber die welt besteht auch aus anderen problemstellungen (platformen etc.).

 

[abdi-61]

@LeMumpelPumpel hab jetzt das else gelösch
doch er zeigt immernoch auf die falsche klammer

 

[antred]

wenn dieser funktion tausendfach un kurzer zeit aufgerufen wird, dann ist meine variante teils um faktor 10 oder gar mehr schneller als deine obigen varianten

Dann probier's mal mit diesem Testprogramm aus:

#include <iostream>
#include <ctime>

struct Data
{
	int* ptrToArray;
};

void cleanup( Data& refToData )
{
	delete [] refToData.ptrToArray;
	refToData.ptrToArray = 0;
}

class RAII_Guard
{
public:
	explicit RAII_Guard( Data& refToData ) : m_refToData( refToData ) {}

	~RAII_Guard()
	{
		cleanup( m_refToData );
	}

private:
	Data& m_refToData;
};

void via_RAII_guard()
{
	Data d = {};

	const std::clock_t start = std::clock();

	for ( std::size_t i = 0; i < 1000000; ++i )
	{
		// do stuff
		//
		// ...
		d.ptrToArray = new int[ 50 ];


		// cleanup guard
		const RAII_Guard g( d );
	}

	const std::clock_t end = std::clock();

	std::cout << "via_RAII_guard .... duration: " << end - start << std::endl;
}

void without_RAII_guard()
{
	Data d = {};

	const std::clock_t start = std::clock();

	for ( std::size_t i = 0; i < 1000000; ++i )
	{
		// do stuff
		//
		// ...
		d.ptrToArray = new int[ 50 ];

		cleanup( d );
	}

	const std::clock_t end = std::clock();

	std::cout << "without_RAII_guard .... duration: " << end - start << std::endl;
}

int main()
{
	via_RAII_guard();

	without_RAII_guard();
}

Bei mir (Release-Build, Visual Studio 2008) ergeben beide Varianten die exakt gleiche Laufzeit. So viel zum Thema Faktor 10. Wenn du das Ablöschen des Speichers noch entfernst, fällt der Boilerplate-Code in der RAII-Guard-Variante stärker ins Gewicht (mit RAII: 516 clock ticks, ohne: 437 clock ticks).

natürlich muss ich das mit try umklammern. und? inwiefern ist das ein nachteil?
muss man in deiner variante übrigens auch und deine aufräum-fuktionen bzw. klassen in den catch/final block setzten.

Ich glaube, du hast mich mißverstanden. Die RAII-Guard-Variante führt die Aufräumarbeiten auch dann aus, wenn vorher im Code eine Exception fliegt, und zwar OHNE, daß ich mit try-catch rumeiern muß, weil das stack unwinding einfach den Destruktor ausführt, egal ob der Stack nun abgeräumt wird, weil ich mit return aus der Funktion rausgegangen bin, oder weil eine Exception geworfen worden ist.

du schuldest mir immer noch die antwort, was dich an dem goto stört.

Es ermutigt Spaghetti-Programmierung, und es gibt immer bessere Alternativlösungen (wie die von mir beschriebenen).

 

[Dese]

Ich glaube, du hast mich mißverstanden. Die RAII-Guard-Variante führt die Aufräumarbeiten auch dann aus, wenn vorher im Code eine Exception fliegt, und zwar OHNE, daß ich mit try-catch rumeiern muß, weil das stack unwinding einfach den Destruktor ausführt, egal ob der Stack nun abgeräumt wird, weil ich mit return aus der Funktion rausgegangen bin, oder weil eine Exception geworfen worden ist.

ah, jetzt verstehe ich. aber was heißt hier rumeiern... jetzt darf ich mal: mach dich nciht lächerlich wegen einem try und final block!

Es ermutigt Spaghetti-Programmierung,

das goto in den allermeisten fällen böse ist habe ich ja nie bestritten. im gegenteil!

und es gibt immer bessere Alternativlösungen (wie die von mir beschriebenen).

öhm... bisher hast du überhaupt nicht gesagt warum deine lösungen besser seien sollen.

der bisher EINZIGE von dir genannte vorteil ist das wegfallen des try-catch/final blocks.
EDIT: im übrigen ist das nur ein möchte-gern-vorteil, wenn es überhaupt etwas gibt, was da ne exception werfen kann. im übrigen in all den situationen, in denen so etwas verwendung gefunden hat gab es das nicht. deswegen hab ich gar nicht daran gedacht

deine varianten brigen ansonsten ALLE nachteile mit, die meine goto variante nicht hat.
du unterschlägst bzw. bagatelisierts die nachteile mit "ist ja nicht meßbar", was zum einen im allgemeinen falsch ist udn zum anderen deine sichtweise offenbar nur auf für dich relevante problemstellungen aufzeigt.

 

[antred]

Grrr. Scheiß-Firefox hat meine Antwort gefressen. Also noch mal ...

ah, jetzt verstehe ich. aber was heißt hier rumeiern... jetzt darf ich mal: mach dich nciht lächerlich wegen einem try und final block!

Ein try-catch Block ist keine kleine Sache! Es ist unwahrscheinlich, daß du jede aufgerufene Funktion bis ins kleinste Detail kennst. Daher kannst du auch nicht wissen, welche Exceptions auftreten können. Wenn du nun Aufräumarbeiten hast, die aber UNBEDINGT ausgeführt werden müssen, mußt du also jede mögliche Exception fangen. Bleibt also nur catch-all. Damit bist du nun aber leider nicht mehr excpetion-neutral; soll heißen, du hast dem Benutzer jede Möglichkeit genommen, auf eine eventuell aufgetretene Exception zu reagieren, da du sie ja einfach "verschluckt" hast.

P.S. Na ja, gut ... du könntest sie nach dem Aufräumen eventuell mit throw; erneut werfen.

das goto in den allermeisten fällen böse ist habe ich ja nie bestritten. im gegenteil!

öhm... bisher hast du überhaupt nicht gesagt warum deine lösungen besser seien sollen.

Habe ich nicht? Ich finde schon.

der bisher EINZIGE von dir genannte vorteil ist das wegfallen des try-catch/final blocks.
EDIT: im übrigen ist das nur ein möchte-gern-vorteil, wenn es überhaupt etwas gibt, was da ne exception werfen kann. im übrigen in all den situationen, in denen so etwas verwendung gefunden hat gab es das nicht. deswegen hab ich gar nicht daran gedacht

deine varianten brigen ansonsten ALLE nachteile mit, die meine goto variante nicht hat.
du unterschlägst bzw. bagatelisierts die nachteile mit "ist ja nicht meßbar", was zum einen im allgemeinen falsch ist udn zum anderen deine sichtweise offenbar nur auf für dich relevante problemstellungen aufzeigt.

Aber ich habe dir doch in dem Beispielprogramm gezeigt, daß der Unterschied überhaupt nur dann (zumindest per clock()) meßbar wird, wenn die vorgenommenen "Aufräumarbeiten" so krass reduziert werden, daß praktisch der gesamte Overhead nur aus dem Instantiieren / Zerstören des RAII-Guards entsteht.

 

[Dese]

Grrr. Scheiß-Firefox hat meine Antwort gefressen. Also noch mal ...


Ein try-catch Block ist keine kleine Sache! Es ist unwahrscheinlich, daß du jede aufgerufene Funktion bis ins kleinste Detail kennst. Daher kannst du auch nicht wissen, welche Exceptions auftreten können. Wenn du nun Aufräumarbeiten hast, die aber UNBEDINGT ausgeführt werden müssen, mußt du also jede mögliche Exception fangen. Bleibt also nur catch-all. Damit bist du nun aber leider nicht mehr excpetion-neutral; soll heißen, du hast dem Benutzer jede Möglichkeit genommen, auf eine eventuell aufgetretene Exception zu reagieren, da du sie ja einfach "verschluckt" hast.

halloooo..... ???? sagte ich das goto immer eine dolle lösung ist?
wir reden hier darüber, dass es SELTENE situationen gibt, in denen goto mindestens eine sehr gote lösung ist. da bringt deine argumentation mit "es kann sein" GAR NICHTS!

P.S. Na ja, gut ... du könntest sie nach dem Aufräumen eventuell mit throw; erneut werfen.

braucht man nicht einmal: final sei dank!
aber ich weiß gar nicht warum dich so an die exception klammerst. wir reden nicht davon, dass goto in allen fällen eine optimale lösung ist. es ging um gewisse situationen! dazu zählen auch situationen, in denen ich nicht auf exception achten muss.

Habe ich nicht? Ich finde schon.

nein überhaupt nicht!
zeig mir wo!

und du hast auch keine nachteile für mein goto gefunden.

Aber ich habe dir doch in dem Beispielprogramm gezeigt, daß der Unterschied überhaupt nur dann (zumindest per clock()) meßbar wird, wenn die vorgenommenen "Aufräumarbeiten" so krass reduziert werden, daß praktisch der gesamte Overhead nur aus dem Instantiieren / Zerstören des RAII-Guards entsteht.

1. hast du das NICHT GEZEIGT!

2. ist das FALSCH! unter anderem aus genau diesem grund WIRD goto im linux kernel verwendet, in crypto-algorithmen, in kompressionalgorithmen und und und VOR ALLEM im embeded systemen sehr wichtig!

3. funktioniert (wie mir später daheim bewust geworden ist) deine rail guard variante für mein beispiel überhaupt nicht:
es gibt in meinem speziellen beispiel 2 verschiedene aufräumarbeiten, wobei eine in der anderen enthalten ist. es kann aber sogar mehrere geben.

deine railguard klasse kann so wie vorgeschlagen nur eine art aufräumen durchführen. wenn du verschiede willst, dann müsste man im programmverlauf

 

[antred]

braucht man nicht einmal: final sei dank!

Final? In C++? Seit wann?

aber ich weiß gar nicht warum dich so an die exception klammerst. wir reden nicht davon, dass goto in allen fällen eine optimale lösung ist. es ging um gewisse situationen! dazu zählen auch situationen, in denen ich nicht auf exception achten muss.

Selbst wenn du in einer Umgebung arbeitest, in der Exceptions kein Thema sind, ist RAII eine ideale Lösung (wenn du obligatorische Aufräumarbeiten hast), weil du sonst entweder dafür sorgen mußt, daß deine Funktion nur einen Ausstiegspunkt hat, oder aber die Aufräumarbeiten an jedem möglichen Ausstiegspunkt explizit anstoßen mußt. Erweitert später mal jemand deine Funktion um einen weiteren Ausstiegspunkt und denkt nicht daran, hast du schon einen Bug. Dem gegenüber wäre die RAII-Variante solchen Änderungen gegenüber unempfindlich. Da hast du also noch einen Vorteil (die du irgend wie alle ständig zu ignorieren scheinst) - RAII resultiert in wesentlich robusterem Code.

nein überhaupt nicht!
zeig mir wo!

und du hast auch keine nachteile für mein goto gefunden.
[...]



1. hast du das NICHT GEZEIGT!

Wenn ich die Vorteile der RAII-Variante aufzähle, ist es doch eigentlich klar, daß du diese Vorteile mit der goto-Variante nicht hast, oder?

2. ist das FALSCH! unter anderem aus genau diesem grund WIRD goto im linux kernel verwendet, in crypto-algorithmen, in kompressionalgorithmen und und und VOR ALLEM im embeded systemen sehr wichtig!

Traust du den Ergebnissen des Beispielprogramms nicht? Wenn nicht, erklär mir bitte warum nicht.

3. funktioniert (wie mir später daheim bewust geworden ist) deine rail guard variante für mein beispiel überhaupt nicht:
es gibt in meinem speziellen beispiel 2 verschiedene aufräumarbeiten, wobei eine in der anderen enthalten ist. es kann aber sogar mehrere geben.

deine railguard klasse kann so wie vorgeschlagen nur eine art aufräumen durchführen. wenn du verschiede willst, dann müsste man im programmverlauf

Verstehe ich nicht ganz (ist da ein Teil deines Posts verloren gegangen)? Was hat die Anzahl der anfallenden Aufräumarbeiten damit zu tun, ob die RAII-Variante funktioniert oder nicht?

 

[Dese]

Final? In C++? Seit wann?

oops... in letzter zeit zu viel java gecoded

Selbst wenn du in einer Umgebung arbeitest, in der Exceptions kein Thema sind, ist RAII eine ideale Lösung (wenn du obligatorische Aufräumarbeiten hast), weil du sonst entweder dafür sorgen mußt, daß deine Funktion nur einen Ausstiegspunkt hat, oder aber die Aufräumarbeiten an jedem möglichen Ausstiegspunkt explizit anstoßen mußt.

du hast schon mein beispiel gesehen oder?

Erweitert später mal jemand deine Funktion...

wen interessiert das? SPEZIELE SITUATION und so! wir reden immer noch davon, dass es situationen gibt in denen goto gut ist und nicht davon, wieviele es gibt in denen es nicht gut ist!

davon abgesehen ist das so wie oben beschrieben leicht zu erweitern. es ist alles kompakt und zusammenhängend.
es gibt im übrigen noch einige andere vorteile dieser goto-variante.

Wenn ich die Vorteile der RAII-Variante aufzähle, ist es doch eigentlich klar, daß du diese Vorteile mit der goto-Variante nicht hast, oder?

lieber antred, ich bitte dich deine posts noch einmal anzuschauen. was du aufgezählt hast ist folgendes:
1. impliziete exception-kompatibilität
2. wird immer ausgeführt, wenn die methode verlassen wird.

meine antwort:
1. irrelevant in vielen spezielen situationen und wir reden von speziellen situation
2. in der spezielen situation wird ohnehin NUR kontrolliert die methode verlassen, also auch irrelevant

3 .dazu kommt, rail guard hat performance einbussen
4. ist nicht anwendbar in meinem beispiel, bzw. nur mit verkomplizierung. erkläre ich ganz unten, weil es deine letzte frage betrifft.

Traust du den Ergebnissen des Beispielprogramms nicht? Wenn nicht, erklär mir bitte warum nicht.

was meinst du damit?

Verstehe ich nicht ganz (ist da ein Teil deines Posts verloren gegangen)? Was hat die Anzahl der anfallenden Aufräumarbeiten damit zu tun, ob die RAII-Variante funktioniert oder nicht?

in meinem beispiel gibt es 3 stellen, an denen abgebrochen wird und die methode verlassen werden soll. zwei der stellen sollen die gleichen aufräumarbeiten durchführen und die andere das gleiche wie die 2 PLUS etwas zusätzliches.

wie unterscheidet deine rail guard WAS genau sie aufzuräumen hat, jeh nachdem WANN wir die methode verlassen?

um das zulösen müsste man z.b. eine variable "int aufräummodus" einführen. diese setzt man jeh nach rpgroammvortschritt. wenn du dann rausgehst checkt der destructor der raild guard klasse was er genau aufzuräumen hat.
dieses verhalten ist
1. unötig mit goto
2. hat zusätzliche if-abfragen und/oder switch
3. eine solche aufräummodus-variable ist nicht sonderlich intutiv verständlich auf den ersten blick.