Compilierungsfehler im Visual Studio 6??

[Hubi333]

Guten Morgen

ich habe ien Programm mit dem Visual Studio (ich glaube das es daran liegt), weil ich nämlich wenn ich mein Programm normal ausführe immer falsche werte bekomme, aber wenn ich es im Debugmodus starte bekomme ich die richtigen Ergebnisse.

Ich benutze das Visual Studio 6 Prof. (Service Pack 5)

unter Windows NT.

Sind auch in dieser Kombination irgendwelche fehl3er bekannt oder liegt es gar nicht daran??

MfG Hubi

[Klotzkopp]

Ohne Dir zu nahe treten zu wollen , ich bin mir aus eigener Erfahrung ziemlich sicher, dass es an Deinem Quellcode liegt, und nicht am Visual Studio, vielleicht an einer fehlenden Initialisierung, die sich im Release-Build anders auswirkt als im Debug-Build. Kannst Du Deinen Quellcode (oder den entscheidenden Teil) posten?

[DBO]

---hat sich erledigt Klotzkopp war schneller----:WD

[Hubi333]

Das ist nicht schlimm, habe ich mit gerechnet das ich einen fehler gemacht habe, aber mir ist so keiner aufgefallen.

Also ich meine es liegt hier dran, was du vielleicht noch wissen müsstest, es sind alles double werte.

kThermometer::getRealreading(kFehler fehler, kSensor sensor)

{

kNormal normal;

kPoisson poisson;

kUniform uniform;

int nSize = sensor.test.size();

for (int i = nSize; i > 0; i--)

{

fehler.createList();

this->error = fehler.createError(normal, poisson, uniform);

this->reading = sensor.test.front();

sensor.test.pop();

this->realreading = this->reading + this->error;

this->printRealreading(this->realreading);

}

}

[Woodstock]

Also Du musst dazu auch die anderen Sachen posten, weil das ja nur ein Auschnitt ist, wo Du auf Bereiche zugreifst, die Du hier nicht zeigst. Es kann ja auch sein das der Fehler dort liegt!

Bine

[Hubi333]

Echt danke für den Kommentar, ist ja nett, das problem ist der andere ****** funktioniert einwandfrei.

UNd da das nicht unbediengt alles an die Öffentlichkeit muss kann ich leider nicht mehr posten.

Mit diesen kommentar habe ich es so verstanden das in diesen Abschnitt alles in Ordnung ist.

Danke für die Hilfe, dann werde ich mal weiter suchen.

[Klotzkopp]

Original geschrieben von Hubi333

Echt danke für den Kommentar, ist ja nett, das problem ist der andere ****** funktioniert einwandfrei.

Das kannst Du nicht wissen. Nur weil der Fehler sich in dem Codefragment, das Du gepostet hast, bemerkbar macht, heißt das nicht, dass er auch da verursacht wird.

Ich nehme mal an, dass printRealReading falsche Werte ausgibt. Dann solltest Du prüfen, ob reading oder error falsch berechnet wird. Gib die beiden Werte doch mal mit aus, dann kannst Du den Fehler zumindest eingrenzen.

[Woodstock]

Sorry, aber ich kenne das von meinen Quelltexten. Nur weil der eine allein richtig läuft, muss es nicht heißen das er im Zusammenhang mit anderen auch richtig läuft. Und wenn ich DIr net helfen wollte, dann hätte ich nicht danach gefragt, sondern einfach nichts geschrieben. Aber ok, so lass ich mit mir nicht umgehen.

Bine

[Woodstock]

Und nochwas! Ich bin nicht hier um Dir Deine Codes zu steheln. Ich schreibe selber welche, suche hier hin und wieder (vielleicht auch öfter) mal Hilfe, und bn froh wenn auch ich mal wem helfen kann!

Bine

[Hubi333]

Es war nicht so gemeint, hab bloß ein bisschen stress.

Ich habe jetzt das problem gefunden.

Es liegt daran das ich meinen Zufallszahlengenerator time(0) übergebe. Im Debugmodus braucht er länger und ich bekomme verschiedene Zufallszahlen. Im main läuft es so schnell durch, das die Zufallszahlen alle direkt hinter einander abgearbeitet werden.

Ich glaube die beste lösung währe ihn nach einer schleife eine bestimmte zeit an zuhalten und dann weiter zu machen.

Fällt euch sonst was besseres ein??

[Klotzkopp]

Rufst Du eventuell srand mehrfach auf?

[Hubi333]

Nein mit srand arbeite ich gar nicht.

srand erzeugt nur periodische Zufallszahlen, was du aber sicherlich schon wissen wirst.

Ich habe mir extra mathe libarys gezogen und umgeschrieben, damit ich eine normalverteilung usw. erzeugt bekomme.

Ich habe jetzt mit sleep eine pause von 1 sec gesetzt und es läuft wunderbar. das problem ist ich muß die windows.h einbinden und das ist nicht so toll. Weist du zufällig wo sleep noch deklariert ist oder ob es nur in der windows.h ist.

[Klotzkopp]

Sleep ist eigentlich in winbase.h, aber die braucht windows.h, da kommst Du also nicht drumherum, wenn Du Sleep verwenden willst. Warum ist das "nicht so toll"?

[Goos]

Hoi,

na das interessiert mich jetzt aber, auf welche Art und Weise du deine Zufallszahlen generierst und vor allem, warum rand fuer dich nicht in Frage kommt.

Wennd magst kannst ja was zu erzaehlen...bin nur mal neugierig.

Goos

[gugelhupf]

also du kannst do sleep simulieren mit asm:

nicht getestet:

while(hier deine Taktzeit)

{

_asm

{

nop

}

}

[Klotzkopp]

@gugelhupf:

Weißt Du zufällig, ob der Assemblercode auch bewirkt, dass der Thread vorzeitig seinen Timeslice beendet? Manchmal liegt es nämlich weniger an der Pause, als an dem erzwungenen Threadkontextwechsel, den man z.B. auch mit Sleep(0) erzeugen kann.

[gugelhupf]

Hmmm...ich denke nicht dass der Timeslice beendet wird...wär mal nen Test wert !

Ich dachte mir nur dass der Thread-Ersteller die windows.h wegen des Overheads nicht einbinden wollte.

Und nur deshalb mein Posting mit asm....

Spart sich halt dann ein paar Scheibchen kostbaren RAM's

[Hubi333]

Danke danke, das mit sleep hat sich aber erledigt, das programm läuft zu lange.

Zu rand: ich hab nichts gegen die rand funktion, das erst einmal vorne weg.

Das Problem bei rand ist das die funktion nur eine periodische Zufallszahl erzeugt, das heißt irgendwann wiederholen sich die Zufallszahlen wieder. Ich weiß jetzt kommen wieder welche die sagen, bis das passiert das dauert ewig, soviel zufallszahlen braucht man nicht.

Das mag zwar stimmen, privat sehe ich es genau so aber wenn ich was in der Firma mache muß es auch vernünftig sein.

Ich hätte diese aufgabe mit rand nicht lösen können, weil ich Zufallszahlengeneratoren brauchte die mir eine Normalverteilung erstellen, eine Gleichverteilung, Poissonverrteilung usw..