Frage zu "volatile"
-
hallo! kennt jemand mit "volatile" aus? ich habe eine code geschrieben, damit ich eine Bild lesen und dann in eine Array speichern kann! code sieht so aus:
int iw,ih; unsigned char *iImage; .. iImage=image.pData; for( ih=0; ih<480; ih++){ for( iw=0; iw<640; iw++){ imag[iw][ih]=*(iImage++); } } .. }mit diesem Code dachte ich, dass ich alles richtig gemacht habe!
meine Programmierenumgebung ist Code Composer Studio(eine Software vom firma TI).bei Code Composer Studio gibt es eine Beobachtunsfunktion, mitdem man die Variable beobachten kann. dann habe ich die Wert von "ih" "iw" und "imag" geschaut! was ich dann nicht verstehen kann ist, dass die "ih" und "imag" alles ok sind, aber bei "iw" habe ich eine Fehlermeldung "identifier not found" . ok, dann habe ich die Wert von "imag" geschaut, was komisch ist, "imag" hat vollständige Werte, 640*480, da fehlt keine einziger Wert?ja,dann habe ich das code noch mal auf VC v6.0 spielen lassen, kein Problem! habe ganzen Tag überlegt, was ich falsch gemacht habe. Dann sagt eine Freund zu mir, dass ich vielleicht mit "volatile" ausprobieren kann. dann habe ich die Code geändert:
.. .. volatile int iw; ..dann funktioniert es wieder mit den Beobachten von "iw". die Fehlermeldung "identifier not found" ist weg! verstehe ich nicht! jetzt meine Fragen:
habe ich es falsch programmiert? oder liegt es an die unterschiedlich Compiler?
und noch mal zu den Fehlermeldung, Weil die Fehlermeldung aus Beobachtensfunktion kommt, denke ich , das die Variable "iw" eigentlich im Hintergrund richitg funktioniert, nur mit dem Beobachten geht es nicht, am sonst sollte ich doch eine falsch "imag" bekommen. oder?
zum "volatile", wann brauchen wir das wirklich in "C" , das ist das erste mal, dass ich das gehört habe. und "volatile" ist doch nur eine Mitteilung an Compiler, hat keine EInfluss auf meine Code , oder?
-
Hast Du beim Debuggen die Code-Optimierung angeschaltet? Wenn ja, könnte es sein, dass der Compiler mit der Variablen irgendwas zwecks Optimierung anstellt, was Dir nicht mehr erlaubt, ihren Wert zu betrachten. Das Schlüsselwort volatile bewirkt ja genau, dass der Compiler mit dieser Variablen keinerlei Optimierung anstellt, da sie ja von außerhalb geändert werden könnte.
-
Mit volatile sagst du, dass die Variable auch durch äußere Einflüsse (OS, anderer Thread...) geändert werden könnte. Das veranlasst den Compiler, den Wert der Variable jedesmal abzufragen, auch wenn in deiner Funktion eigentlich keine Änderung stattgefunden hat.
-
heißt das, dass mit "Volatile" sage ich zu dem Compiler, dass die Compiler immer meine Variable beobacgten soll? heißt das aber auch, wenn ohne "Volatile" wird das Programm weiter richtig laufen, nur mit dem Beobachten kann ich nicht. habe ich richtig verstanden?
ich habe meine andere For-Schleife kontrolliert, die selbe Fehler habe ich auch dort gefunden, und komischweise ist immer die hälft von die def. Variablen nicht im Ordnung. ist das eine Zufall, dass immer die Hälft davon ausfällt?
-
Mit volatile sagst Du den Compiler nicht, dass er etwas beobachten soll, sondern lediglich, dass der mit dieser Variablen keine Optimierungen anstellen darf. Ohne volatile kann er die Variable in ein Register oder einen Cache packen, so dass sie als Symbol nicht mehr existiert. Gerade bei inneren Schleifen mit Schrittweite 1 ist sehr wahrscheinlich, dass sowas passiert.
Aber die Lösung wurde schon genannt: Wenn Du Debuggen willst, schalte Optimierungen ab. Sämtliche Optimierungen.
-
LordJaxom schrieb:
Aber die Lösung wurde schon genannt: Wenn Du Debuggen willst, schalte Optimierungen ab. Sämtliche Optimierungen.
Würde ich nicht so pauschal behaupten. Gerade wenn ein Compiler die Möglichkeit bietet, zu optimieren, ohne die Debug- Informationen zu zerstören, ist das öfters hilfreich, weil man dann Codeteile sofort sieht, für die kein Objektcode erzeugt wurde, meist irgendwelche Bedingungen, die immer wahr oder falsch sind.
An "volatile" darf übrigens auch kein noch so forscher Optimierer ran, weil es besagt, daß bei jedwedem Lesen oder Schreiben immer der Ursprung bemüht werden muß, kein durch wen auch immer gecacheter Inhalt.
Das ist völlig unabhängig von Debug/Release/Optimierung, sondern Sprachstandard
-
Stimmt alles. Ich hätte wohl sagen sollen "wenn Du den Ursprungscode ohne Überraschungen debuggen willst, schalte Optimierungen ab".
Durch das volatile hat der OP ja explizit Optimierungen an der inneren Schleifenvariable verboten, wodurch diese im Debugger sichtbar wurde. Um sinnvoll schrittweise debuggen zu können, und damit auch Stacktraces an die richtigen Stellen zeigen (wg. nicht erfolgtem Inlining), schaltet man halt am besten alles ab.
-
pointercrash() schrieb:
...weil man dann Codeteile sofort sieht, für die kein Objektcode erzeugt wurde, meist irgendwelche Bedingungen, die immer wahr oder falsch sind.
die kann man oft auch als warnungen beim compilieren anzeigen lassen.
-
fricky schrieb:
die kann man oft auch als warnungen beim compilieren anzeigen lassen.
Unbestritten - aber oft kriegt man beim Compilieren einen Sack voll Warnings präsentiert, die überwiegend irrelevant sind - wer sieht denn, daß zur 42. warning die 43. hinzugekommen ist?
Ich nicht immer, aber wenn ich keinen Breakpoint auf eine verdächtige Zeile setzen kann, weiß ich Bescheid. Nix anderes war gemeint.
-
pointercrash() schrieb:
fricky schrieb:
die kann man oft auch als warnungen beim compilieren anzeigen lassen.
Unbestritten - aber oft kriegt man beim Compilieren einen Sack voll Warnings präsentiert, die überwiegend irrelevant sind - wer sieht denn, daß zur 42. warning die 43. hinzugekommen ist?
Ich nicht immer, aber wenn ich keinen Breakpoint auf eine verdächtige Zeile setzen kann, weiß ich Bescheid. Nix anderes war gemeint.Dann schreib sauberen Code, dann hast du auch keine Warnings.
-
Prokkramierer schrieb:
Dann schreib sauberen Code, dann hast du auch keine Warnings.
Um`s mal historisch zu bewerten:
Ein Tor, wer dabei Schlechtes denkt.
Was kann ich dafür, daß VStudio von OCX heute nichts mehr wissen will? Die Druckfunktion geht halt nimmer - mein Programm ist dadurch nicht schlechter geworden, es produziert beim Compilieren nur jede Menge Warnings, die kein Mensch interessiert- über das Ding ist wohl nie gedruckt worden.
Mir ist das egal, solange der Kunde mit den Migrationsproblemen leben kann und das Aufräumen nicht bezahlen mag.
In der Kiste sinds so um die 200 Warnings, aber solange das Ding tut, wird man mir wohl nichts Neues antragen.