Ich werd noch bekloppt; Im genullten Array befindet sich einfach ein Wert
-
Mahlzeit
Ich sitze jetzt seit 8 Uhr morgens an einem Fehler und finde ihn nicht, also es gibt folgende Klasse:
struct Zoomed { unsigned int zoomed[4][10]; }; // grob zusammengefasst class Foo() { Foo(); private: Zoomed runtimesZoomed; };
Sie enthält also eine Struktur welche wiederum ein zweidimensionales Array enthält. Hier der Konstruktor von Foo():
for(int i=0; i<4; ++i) for(int j=0; j<10; ++j) runtimesZoomed.zoomed[i][j] = 0; cout<<"Konstruktor aufgerufen, [3][9] = "<<runtimesZoomed.zoomed[3][9]<<endl;
Es wird auch schön brav 0 ausgegeben.
Von außerhalb der Klasse kommt man nur über eine Methode an das array ran:
const Zoomed* Foo::GetZoomedRuntimes() { return(&runtimesZoomed); }
Also const, man kann nicht von außen reinschreiben.
Innerhalb der Klasse wird dieses Array nur in einer Methode verwendet:
void Foo::StoreRuntime(T *ptrT) { double difference = ptrT->GetSentReceivedDifference(); int vk = GetVorkomma(difference); int nk = GetNachkomma(difference); if(difference < 4) { // ++runtimesZoomed.zoomed[vk][nk]; auskommentiert!! // ++numberOfRuntimesZoomed; if(vk == 3 && nk == 9) { ofstream log("nerv.txt", ios::app); log<<runtimesZoomed.zoomed[3][9]<<endl; } [...] }
Und in nerv.txt stehen immer wieder die gleichen Werte:
**
97
97
98
98
98
98
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
101
102
103
103
103
104
104
104
104
104
104
104
105
105
105
105
105
105
105
105
106
106
106
106
106
106
106
107
107
108
108
108
108
108
108
108
108
108
108
108
109
109
109
109
109
109
109
109
109
109
109
109
109
109
109
109
109
110
110
110**Wenn ich am Anfang von StoreRuntime
runtimesZoomed.zoomed[3][9] = 0;
schreibe ist der Wert 0, so wie es sein sollte.Das würde heißen das zwischenzeitlich doch am Array rumgefummelt wird, aber ich habe eben zum 1000x mal nachgesehen, nirgendwo veränder ich den Inhalt!
Seht ihr was falsch sein könnte? Nirgendwo sonst wird runtimesZoomed.zoomed verändert, definitiv! Ich habe auch schon anstatt dem Visual Studio den gcc genutzt, selbes Ergebnis ich weiß einfach nicht mehr weiter
-
vielleicht jetzt etwas absurd, aber vielleicht hattest du mal einen durchlauf gemacht, ohne
// ++runtimesZoomed.zoomed[vk][nk]; auskommentiert!! // ++numberOfRuntimesZoomed;
auszukommentieren und schaust jetzt immer in die alte datei. denn wenn alles 0 ist, wird ja nichts neues reingeschrieben, folglich wird die datei nicht verändert.
folgendes wird ja gar nicht aufgerufen, wenn jedes element des arrays 0 ist:ofstream log("nerv.txt", ios::app); log<<runtimesZoomed.zoomed[3][9]<<endl;
war nur so meine erste idee...vielleicht hat's ja geholfen.
regards usw...
-
probiers mal mit extra klammerung bei der if abfrage
if((vk == 3) && (nk == 9)) { ofstream log("nerv.txt", ios::app); log<<runtimesZoomed.zoomed[3][9]<<endl; }
-
der wahnsinn schrieb:
probiers mal mit extra klammerung bei der if abfrage
if((vk == 3) && (nk == 9))
Nee, daran liegts mit Sicherheit nicht. Die Operatorenrangfolge sorgt schon dafür, dass das richtig ausgewertet wird.
-
So, jetzt melde ich mich noch einmal:
Ich habe noch sehr viel Zeit aufgewandt um den Fehler zu finden weil mich das nicht in Ruhe gelassen hat hat, ich habe alles auskommentiert wo dieses Array auch nur annähernd verwendet wurde, der Fehler war immer noch da.
Ich habe jetzt einfach ein Backup ausgegraben und dort weitergearbeitet, auch wenn ich da Änderungen nachtragen musste.
-
anstatt
for(int i=0; i<4; ++i) for(int j=0; j<10; ++j) runtimesZoomed.zoomed[i][j] = 0;
kannst du auch
memset(&runtimesZoomed, 0, sizeof(runtimesZoomed));
schreiben
-
Hatte ich auch schon probiert, wobei das aber glaube ich betriebssystemspezifisch war und das Programm auch unter Linux läuft. Nicht haun wenn ich mich irre
-
wahnsinniger schrieb:
wobei das aber glaube ich betriebssystemspezifisch war und das Programm auch unter Linux läuft.
"Das glaube ich nicht, Tim"
Ist aber einfach ein Stück schneller, und einfacher zu Handhaben, falls du mal deine Zoomed Struktur auf irgendeine Weise änderst
-
Es funktioniert zwar dann auf allen "vernünftigen" Maschinen/Compilern, aber ist eben doch nur eingeschränkt portabel im Gegensatz zu den for-Schleifen.