"ungültige Gleitkommaoperation" in Funktion, die nichts berechnet

[susie]

staun, das wußt ich gar nicht, daß das geht.
Na ja, im Grunde glaub ich nicht, daß das mein Problem ist, da meine Indizes immer in for-Schleifen hochgezählt werden, immer bis zur selben Grenze, aber ich werds im Hinterkopf behalten.

[susie]

Doch noch ne Frage zu den Initialisierungslisten, zu der ich in den Büchern keine Antwort gefunden hab: Wenn ich das mache, muß ich dann jedes Member in dieser Liste angeben? Oder kann ich mir nur grad die Pointer raussuchen und diese mit 0 initialisieren, die restlichen Member so lassen, wie sie sind (mag in fremden Code so wenig wie möglich ändern)?

[drakon]

Ja, kannst du.

Die ersten 2 Einträge sollten schon genügen..
http://www.google.ch/search?q=initialisierungsliste+c%2B%2B&ie=utf-8&oe=utf-8&aq=t&rls=org.mozillaofficial&client=firefox-a

Grundsätzlich sollten aber alle Member initialisiert werden, um Probleme zu vermeiden. Aber besser die Zeiger, als gar nichts.

[susie]

Hm, weit bin ich damit nicht gekommen, die wenigsten Pointer sind Member einer Klasse.
Außerdem ist eine neue Frage aufgetaucht: Wenn ich ein Array von Pointern hab, wie kann ich das denn initialisieren? (außer in einer Schleife?)

[Nexus]

susie schrieb:

Wenn ich ein Array von Pointern hab, wie kann ich das denn initialisieren? (außer in einer Schleife?)

Wie alle Arrays.

Normalerweise kannst du die Array-Initialisierungsliste verwenden. Arrays als Member können nur mit Schleifen initialisiert werden (du kannst natürlich auch Funktionen wie std::fill() oder std::generate() verwenden.

[susie]

Also, ich hab den Fehler jetzt weiter eingegrenzt: Und zwar ist in der Initialisierung eine for-Schleife mit 4 Anweisungen drin, wenn ich die auskommentiere, läuft es über die vorige Fehlerstelle drüber.

Und zwar hat die Klasse, die diese for-Schleife enthält, neben anderen Arrays (alle derselben Größe) als Member ein Array
Soil* soilgrid[xsize][ysize];

Besagte for-Schleife sieht so aus:

for (int i=0; i<xsize; i++) {
		for (int j=0; j<ysize; j++) {
			soilgrid[i][j] = new Soil( ... eine Liste mit knapp 20 Parametern...);
			soilgrid[i][j]->aspect = aspect[i][j];
			soilgrid[i][j]->inclination = inclination[i][j];
			soilgrid[i][j]->setAspectFactor();
		}
	}

Soil ist eine Klasse mit ca. 40 Datenmembern, vorwiegend double. In den beiden Konstruktoren, einmal ohne, einmal mit Parametern, habe ich nun für alle Member eine Initialisierungsliste zugefügt (entweder 0.0 genommen, ansonsten die Werte, die als Parameter angegeben waren).
Mehr als eine Zuweisung von Werten (teilweise von Berechnungsergebnissen) an die Datenmember passiert nicht im Konstruktor (es werden auch nicht allen Membern Werten zugewiesen).
Trotzdem, wenn ich die Zeilen 3-6 auskommentiere, tritt der Fehler nicht auf. Wenn ich nur Zeiln 4-6 auskommentiere, aber schon, weswegen ich denke, daß es am Konstruktor liegen muß. Aber was kann das denn dann sein?!

[susie]

Der Fehler tritt auch auf, wenn ich alle Zuweisungen in dem Konstruktor mit den Parametern auskommentiere und auch, wenn ich die soeben erstellte Initialisierungsliste auskommentiere. Aber das macht doch dann gar keinen Sinn, dann müßte es ja an dem Array liegen, aber die Arraygrenzen und die for-Schleife sind doch von daher ok? Oder hab ich Tomaten auf den Augen?

Hab ich unterwegs irgendwelche falschen Schlußfolgerungen gezogen?

[rean]

Hat Soil* soilgrid[xsize][ysize]; die konstanten Grenzen xsize und ysize oder wird es dynamisch erzeugt?
Falls ja: zeig mal die entsprechende Codestelle.

Erbt Soil von anderen Klassen?
Falls ja: Was passiert in den Konstruktoren der Superklassen?

[susie]

Die Grenzen vom Array sind konstant. Wie die anderen arrays auch (alle der Größe xsize*ysize und xsize und ysize sind Konstanten).

Soil erbt nicht von anderen Klassen.

[susie]

Noch mal ne ganz grundsätzliche Frage:
Bislang dachte ich bei einem Fehler immer, wenn ich irgendwas auskommentiere, und dann läuft es über diese Fehlerstelle drüber, dann ist die URsache im Auskommentierten zu suchen. Aber ist das zwingend so?

[susie]

Jetzt scheint es zu klappen.

Also ursprünglich war es so (=was ich vorher in main schrieb, aber da hatte ich die Initialisierung von dem Code meiner Kollegin (=das mit der for-Schleife und dem Soil =initialiseSoil) nicht mit aufgeführt).

int main(int argc, char* argv[])
{
        A* a;

	initialiseSoil();
        a=new A();
        a->calculate();
        return 0;
}

Nun hab ich die Objekterzeugung von Klasse A vorgezogen, damit geht es.

int main(int argc, char* argv[])
{
        A* a;

	a=new A();
	initialiseSoil();
        a->calculate();
        return 0;
}

Kann man daraus irgendwelche Schlüsse ziehen?
Ich bin jetzt erstmal total froh, daß es soweit läuft (und muß da erstmal wieder aufräumen). Aber eine wirkliche Fehlerlösung ist das ja nicht. Und wo ich den Fehler dann suchen soll, weiß ich immer noch nicht.
Seht ihr da noch irgendwas, wo man das eingrenzen kann? Seht ihr das noch wie vor als Problem mit Pointern?
(Das mit den SmartPointern ist ja schön, aber da verstehe ich noch zu wenig, wie man Code von ganz woanders her einbindet -zumindest mein Eindruck nach Überfliegen der Webseite)

[drakon]

Es könnte sein, dass du den Fehler nur wieder verschiebst. Aber wenn es geht, dann ist ja schon einmal gut.
Kommt halt drauf an, was du alles in initialiseSoil machst. Ich habe mittlerweile die Übersicht über deinen Code verloren. - Darum wäre ein wirklich lauffähige Version, die den Fehler enthält praktisch gewesen.

[Dravere]

drakon schrieb:

Darum wäre ein wirklich lauffähige Version, die den Fehler enthält praktisch gewesen.

Nicht nur läuffähig, sondern am besten auch noch lesbar.

susie schrieb:

Und ich glaube auch nicht, daß die Originalbezeichnungen viel weiterhelfen würden, wenn man die Anwendung nicht kennt.

So einer Aussage kann ich nur widersprechen. Es ist äusserst unangenehm, wenn man sich irgendwelche Buchstaben als Klassen erinnern muss. Es ist deutlich lesbarer, wenn man die Funktion der Klasse gleich an ihrem Namen ablesen kann. Dies gilt übrigens auch für die Variablen.

A a;
B b = a.b();
C* c = b.do_a();
c->xyz();

Da versteht ja niemand, was hier abgeht. Und wenn das über mehrere hundert Zeilen so abgeht, dann ist das für den Leser eher Buchstabensuppe als Programmcode

Grüssli

[susie]

Was in initialiseSoil passiert, weiß ich auch nicht, ich kenne den Code ja auch nicht wirklich, ist ja nicht meiner.

Hm, das gesamte Programm sind 24 Klassen, insgesamt 411 KB Quelltext (weiß nicht, wieviel Lines of Code), manches davon BorlandBuilder-spezifisch. Meint ihr, das geht überhaupt und bringt was, es so zu posten?
Ich bin da auch ein bißchen zögerlich, das alles 1:1 öffentlich zu posten, weil es nicht nur mein Code ist und alles halt nichts privates.
Oder kann ich das jemandem als Mail schicken? Macht zu Testzwecken aber auch nur Sinn, denk ich mal, wenn man es mit dem BorlandBuilder testen kann?!

[Dravere]

Eine lauffähige Version muss nicht das ganze Programm sein. Nur der wesentliche Teil, wo der Fehler auftritt. Das können schlussendlich auch nur 20 Zeilen sein, müssen aber eben ausführbar sein.

Solche kleine Test-Programme helfen einem auch selber, da man dadurch den Fehler eingrenzen kann.

Den anderen hilft es, dass sie den Debugger verwenden und sich die Fehler selber anschauen können. Zudem ist ein kleiner Code deutlich schneller zu verstehen, als ein ganzes Projekt. Wodurch der Fehler deutlich schneller gefunden werden dürfte.

Und wegen initialiseSoil:
Naja, so wie es aussieht, könnte von dort der Fehler kommen. Oder zumindest könnte der Code dort drin mit dem Code in deinem A Konstruktor zusammenhängen. Daher wäre es schon praktisch, wenn du wüsstest, was dort drin vorgeht

Grüssli

[susie]

Hallo,

so, jetzt mache ich mich systematischer auf die Fehlersuche, durchsuche erstmal ob alle new's ein entsprechendes delete haben und ob die Pointer alle mit 0 initialisiert werden. Mein eigener Code scheint soweit ok, nun bin ich an dem Code meiner Kollegin. Dabei ist mir folgendes aufgefallen:

Und zwar ist veggrid eine Instanzvariable einer Klasse:

Veg* veggrid[xsize][ysize];

im Konstruktor der Klasse passiert folgendes (in einer Schleife für die Indizes):

veggrid[i][j] = new Veg();

im Destruktor der Klasse (auch in einer Schleife):

veggrid[i][j]->~Veg();

Ich hätte in der Situation im Destruktor folgendes gemacht (auch in einer Schleife):

delete veggrid[i][j];

Nun bin ich ein bißchen irritiert. Kommt das auf dasselbe raus? Oder was ist besser?

Danke mal wieder!

[dooooomi]

susie schrieb:

im Destruktor der Klasse (auch in einer Schleife):

veggrid[i][j]->~Veg();

Ich hätte in der Situation im Destruktor folgendes gemacht (auch in einer Schleife):

delete veggrid[i][j];

Nun bin ich ein bißchen irritiert. Kommt das auf dasselbe raus? Oder was ist besser?

Die erste Variante ist schlicht und einfach falsch. Den Destruktor direkt aufzurufen ist nur im Zusammenhang mit Placement-New sinnvoll, und das liegt hier ja nicht vor.

Delete ruft automatisch den richtigen Destruktor auf, bevor es den Speicher freigibt. Der Destruktoraufruf alleine gibt aber den Speicher des Objekts nicht frei, d.h. im besten Fall hast du dadurch zumindest ein Speicherleck.

[susie]

Hallo,

das Problem zu Anfang des Jahres schien gelöst zu sein, jedenfalls lief es wieder, nachdem ich den Code nochmal durchforstet habe und sämtliche Instanzvariablen incl. Pointer initialisiert habe. Das Hauptproblem war wohl tatsächlich die Nichtinitialisierung einiger Instanzvariablen und der mangelhafte Destruktor wie oben beschrieben. Der Code lief dann die ganze Zeit, auch als ich einige kleine Änderungen gemacht habe.
Nun habe ich einige "umfangreichere" Änderungen gemacht. Na ja, hab in einer Klasse 2 Arrays als Instanzvariablen eingefügt und in einer anderen Klasse eine double-Instanzvariable und entsprechende Zugriffsfunktionen implementiert. Jedenfalls stehe ich nun wieder vor demselben Problem: Ich bekomme die Fehlermeldung "Ungültige Gleitkommaoperation", obwohl da keine Gleitkommaoperation ist. Durch Auskommentieren ließ sich der Fehler darauf beschränken, daß er auftritt, wenn ich die double-Instnazvariable mit einer "set..."-Methode setze, und das tritt in der Anfangsphase des Programms auf, vor den eigentlichen Berechnungen. Ich habe jetzt in der set-Methode dummy-Werte von 0.5 zugewiesen, aber trotzdem. Also wird es wohl wieder so sein wie beim letzten Mal daß es ganz woanders hängt.
Eigentlich hatte ich, wie gesagt, den gesamten Code zu Anfang des Jahres durchforstet. Bleibt mir wohl nichts anderes übrig, als es nochmal zu tun, vielleicht hab ich ja was übersehen. Aber vielleicht kann mir ja nochmal jemand sagen, worauf ich achten muß: Nicht initialisierte Instanzvariable, nicht-initialisierte Pointer, die dadurch irgendwohin zeigen,... Noch irgendwas oder andere Hinweise?

Vielen DAnk!

[unskilled]

Zeig mal, wie du die Instanz deiner Klasse anlegst - ansonsten hast du eigtl scho alles, was mir einfallen würde, aufgezählt^^

bb

[audacia]

Kannst du den Fehler in einem weitergabefähigen Minimalprojekt reduzieren?

Auch könntest du mal CodeGuard aktivieren.