ja, ich weiß, goto ist verpöhnt von vielen C++-Proggern,
aber dennoch gibt es wie ich denke, Situationen, wo es hilfreich sein kann.

Jetzt zu meiner Frage:
Ist der Destruktor-Aufruf in folgendem Beispiel garantiert?

#include<iostream>

class MyClass {
public:
  MyClass() {
    std::cout << "MyClass" << std::endl;
  }

  ~MyClass(){
    std::cout << "~MyClass" << std::endl;
  }
};

int main(){
        for(int i=0; i<10; ++i){
                for(int j=0; j<10; ++j){
                        MyClass c;
                        if((i+j) % 15 ==0 && i-j==1){
                                std::cout << "found" << std::endl;
                                goto procEnd;
                        }
                }
        }
        procEnd:{}
        return 0;
}

Gruß,
CSpille

Außerdem... nur so als Frage.. kann man die Durchläufe mit der Initialisierung j=i in der for() nicht deutlich verkürzen oder wäre dies hier in dem Falle fehl am platz und nur bei Sortierung sinnvoll?

Braucht man goto nicht eigentlich nur, wenn man einen Lexer, oder ähnliche Dinge schreiben will? Letztendlich könntest du eine 2. Variable einführen (einen bool) der dann true oder false gesetzt wird, wo du das goto aufrufen würdest, und das mit && in den for() Bedingungen mit überprüft wird... Also ich sehe keinen Anlass für goto, wenn man es auch anders lösen kann...

goto ist besser als künstliche variablen. aber sowas von.
goto kann man auch anders loswerden. meistens durch auslagern und returnen.
und for-schleifen-bedingungen wollen schon mal gar nicht überfrachtet werden.

(Ich meine die paar Byte für ne "künstliche Variable" :D)

Um die gehts mir gar nicht.

a) Man stellt mit if einen Sachverhalt fest und springt bei Vorliegen des Sachverhalts dahin, wo man es verarbeiten mag.

b) Man stellt mit if einen Sachverhalt fest und merkt ihn sich in einer Variablen, springt aber nicht weg, sondern läuft normal weiter, um dann später nochmal mit if diesmal anhand der Variablen den Sachverhalt nochmals festzustellen und zu verarbeiten bzw per if bei Nichtvorliegen die Verarbeitung zu überspringen.

Blackskyliner schrieb:

in meiner persönlichen Liste zu "Streitthema" hinzufügen

Sogar zu den Religionsthemen.

Okay, wieder was dazu gelernt, wobei es eine Sache des Styles ist oder? (Ich meine die paar Byte für ne "künstliche Variable"

Absolut eine Frage des Stils. Es geht dabei nicht "um ein paar Bytes"; die Entscheidung für oder wider goto wird nicht aufgrund technischer Gründe getroffen. Auf diesem Level optimieren zu wollen ist sowas von sinnlos.
Man nimmt das, was logisch ist, was den Leser den Code am einfachsten verstehen lässt. Manchmal, aber nur manchmal, haben Coder ein kleines bisschen goto gern. Ich habs jenseits von asm und Basic noch nie gebraucht.

In dem Fall könnte man ein continue; machen wenn die sprungBool gesetzt ist, am besten dann in beiden Schliefen, damit dürfte es auch deinen Ansprüchen genügen.

Dann mußt Du mir mal bei folgendem Problem helfen:

#include <iostream>
using namespace std;

int main(){
	for(int kandidat=2;kandidat<100;++kandidat){
		for(int teiler=2;teiler*teiler<=kandidat;++teiler){
			if(kandidat%teiler==0){
				goto keinePrimzahl;
			}
		}
		cout<<kandidat<<' ';
		keinePrimzahl:;
	}
	return 0;
}

Als Mensch gehe ich so vor. Ich teste alle möglichen Teiler und wenn einer den Kandidaten teilt, ist es eben keine Primzahl und ich mache deswegen einfach mit dem nächsten Kandidaten weiter. Ich habe Angst, daß Zwischenvariablen hier die Einfachheit bombardieren. Und break/continue gehen nicht, um aus der inneren Schleife die äußere zu steuern.

Dann mußt Du mir mal bei folgendem Problem helfen

bool isPrime(int);

return ist zwar auch nur ein goto, aber das hier ist doch ein schöner Fall, in dem man seinen Code übersichtlicher und besser strukturiert macht, wenn man die innere Schleife in eine Funktion auslagert.

Ich geb zu wenige übersichtlich, vor allem wenn mann dann mehr als nur den Kandidaten ausgeben will und entsprechend noch verarbeiten will aufgrund der Bedingung... aber es ist möglich Wobei man schon sagen muss, dass ein goto eleganter erscheint

EDIT: @Michael E.: Sein Beispiel war ja dazu gedacht, meine Aussage zu "entkräften".

Ehrlich gesagt hab ich jetzt mit einer 'Wie kann man nur goto verwenden?'-Diskussion gerechnet

#include <iostream>
using namespace std;

bool isPrime(int kandidat) {
	for (int teiler=2;teiler*teiler<=kandidat;++teiler) {
		if (kandidat%teiler==0) {
			return false;
		}
	}
	return true;
}

int main() {
	for (int kandidat=2;kandidat<100;++kandidat) {
		if (isPrime(kandidat)){
			cout<<kandidat<<' ';
		}
	}
	return 0;
}

Aber auf die Idee, das als Funktion auszulagern um das goto zu umgehen muss ich mir mal merken

Aber auf die Idee, das als Funktion auszulagern um das goto zu umgehen muss ich mir mal merken

Es geht nicht darum das goto zu umgehen, weil es böse ist, sondern darum den Code logisch zu Gliedern und Konzepte auszulagern, was sehr Vorteilhaft ist.

Bei volkards Beispiel sieht man sofort, was es machen soll, während man bei den anderen Beispielen zuerst den Code wirklich anschauen muss, damit man versteht, was er machen soll.
Und das ist nur einer von vielen Vorteilen (Wartbarkeit, Wiederverwendbarkeit, Lesbarkeit, Fehleranfälligkeit usw.)

Blackskyliner schrieb:

Aber auf die Idee, das als Funktion auszulagern um das goto zu umgehen muss ich mir mal merken

Es geht nicht darum das goto zu umgehen, weil es böse ist, sondern darum den Code logisch zu Gliedern und Konzepte auszulagern, was sehr Vorteilhaft ist.

Bei volkards Beispiel sieht man sofort, was es machen soll, während man bei den anderen Beispielen zuerst den Code wirklich anschauen muss, damit man versteht, was er machen soll.
Und das ist nur einer von vielen Vorteilen (Wartbarkeit, Wiederverwendbarkeit, Lesbarkeit, Fehleranfälligkeit usw.)

Nicht immer. Also ich kenne auch folgendes Szenario nur all zu gut.

Irgendwie ist das Verfahren kompliziert und unübersichtlich. Man lagert aus, um das goto oder die künstliche Variable loszuwerden. Und dann erst kapiert man, was man ausgelagert hat und daß es gut ist. Und man kann dem Ausgelagerten einen sinnvollen Namen geben. Und dadurch erst begreift man das Verfahren.

Ich wollte damit ja sagen, dass man ein goto nicht einfach per se umgehen muss, sondern dass es einfach ein Indikator für zu komplizierte Systeme ist und man da besser nochmal drüber geht, was zur Folge hat, dass es sowieso wegfällt.

Gruß,

Simon2.