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

[susie]

Was helfen könnte, wäre sicher auch noch die Initialisierungsliste zu benutzen und alle Zeiger auf 0 zu setzen. Dann musst du ihnen vor der Benutzung einen Wert zuweisen und es kann nicht sein, dass es zufälligerweise doch funktioniert..

Ach so, Du meinst es so herum, daß ein Pointer deklariert wurde, aber NOCH einen undefinierten Wert besitzt. Und der dann verwendet wird, obwohl er noch nicht initialisiert wurde? Dann müßte ich den Code auf alle Pointer durchforsten (Suche nach "*") und diese mit 0 initialisieren.

Ich dachte, daß du meinst, daß ein Pointer verwendet wurde, aber nach der Benutzung nicht auf 0 zurückgesetzt wurde, so daß man evtl. auf Werte zurückgreift, die nicht mehr wirklich gültig sind (ist ja auch möglich, aber zumindest wird dabei nichts soooo unplausibles rauskommen oder ist unwahrscheinlicher).

[drakon]

Nun ja. Deletes sollten eigentlich immer in direktem Zusammenhang mit den jeweiligen new's sein. Da du ansonsten im Falle von z.B einer Exception ziemlich sicher Speicherlecks bekommst. Ich würde euch dringend anraten Smart Pointer zu benutzen.
http://www.boost.org/doc/libs/1_37_0/libs/smart_ptr/smart_ptr.htm

Naja. Du hast ja Arrays und wenn du nun ausserhalb von gültigem Speicher zugreist, kann ein solcher Fehler auch vorkommen. (Auch wenn die Boundchecks stimmen, kann es sein, dass gar kein Speicher angefordert wurde und dann sonst wo zugegriffen wird).

Initialisierungsliste ist die einzige Möglichkeit eine (nicht-statische) Variable innerhalb einer Klasse zu initialisieren.

class foo
{
 foo ()
 :        //Anfang einer Initialisierungsliste
 i ( 2 ), // jede Member mit einem Startwert füllen
 pi ( 0 ), // Zeiger am besten auf 0
 ci ( 42 ) //einzige möglichkeit einen const Wert zu initialisieren
 {
  i = 5; // das hier ist niemals eine initialisierung, sonder immer eine Zuweisung
  ci = 993; // niemals möglich, da eine konstante ihren Wert bei der Initialisierung bekommt
 }

 int i;
 int* pi;
 const int ci;
};

Naja. Ich kann jetzt eigentlich nicht mehr viel machen, ausser zu sagen, dass du das schon noch mit ein wenig Geduld hinbringen kannst. Freunde dich mit deinem Debugger an und geniese die paar Stunden Debugging Sessions und dann das, was am wichtigsten ist. Lern im nachhinein aus deinen Fehlern!

[susie]

Tja, das mit der Geduld ist so ne Sache. Wenn man nicht irgendwelchen Zwängen von außen unterliegen würde... Na ja, mal sehen, wie ich den besten Kompromiß finde... (auch das mit den SmartPointern: hört sich ganz gut an, aber bis Januar muß es erstmal einfach nur irgendwie funktionieren, und einiges mehr)

Ok, mit dem direkten delete einbauen mach ich es in Zukunft anders. Aber in dem Fall müßte es doch wirklich am Code meiner Kollegin liegen, oder kann man das so definitiv auch nicht sagen?

Naja. Du hast ja Arrays und wenn du nun ausserhalb von gültigem Speicher zugreist, kann ein solcher Fehler auch vorkommen. (Auch wenn die Boundchecks stimmen, kann es sein, dass gar kein Speicher angefordert wurde und dann sonst wo zugegriffen wird).

Wie kann das gehen? Wenn ich ein Array deklariere, wird doch automatisch Speicher dafür angefordert?! Und wenn ich es nicht deklariere, kann ich es auch nicht verwenden?!

Aber diese Möglichkeit als Fehlerquelle gibt es ja auch noch?! :

Ich dachte, daß du meinst, daß ein Pointer verwendet wurde, aber nach der Benutzung nicht auf 0 zurückgesetzt wurde, so daß man evtl. auf Werte zurückgreift, die nicht mehr wirklich gültig sind

Jedenfalls vielen Dank nochmal!

[Dravere]

susie schrieb:

Wie kann das gehen? Wenn ich ein Array deklariere, wird doch automatisch Speicher dafür angefordert?! Und wenn ich es nicht deklariere, kann ich es auch nicht verwenden?!

char myArray[20];
myArray[200] = 34;

// Oder
char* p = new char[20];
p[30] = 3;

delete[] p;

Das ist gültiges C++ mit gesichertem undefiniertem Verhalten
Also ein standard konformer Kompiler wird das kompilieren, zur Laufzeit wird aber irgendetwas seltsames oder auch nichts passieren. Es ist halt nicht definiert, was passieren wird.

Grüssli

[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!