Volatile in C++

[Martin (Gast)]

Hallo Leute!

Ich programmiere schon seit einiger Zeit Microprozessoren in C. Wenn ich 
nun eine Variable hatte, auf welche ich aus dem Hauptpgrogramm und aus 
einer IRQ-Routine zugreifen wollte, habe ich die Codeoptimierung mittels 
"volatile" abgeschaltet.

volatile uint16_t test=0;

Nun bin ich aber dabei, dass ich meine ersten Gehschritte in C++ mache.
Hier ist es möglich, ganze Klassen als Volatile zu instanziieren. Ich 
verstehe nicht, warum nach einer "volatile"-Instanziierung der Klasse 
auch die Methoden von "volatile" sein müssen, falls sie benutzt werden. 
In C bezieht sich das "Volatile" ausschließlich auf Variablen 
(Datentypen) und nicht auf Funktionen.

class auto
{
public:
uint16_t geschwindigkeit;
uint16_t farbe;
uint16_t gewicht;

uint16_t blinker_ein(uint16_t var);
uint16_t blinker_aus(uint16_t var) volatile;
}

...

int main(void)
{
volatile auto v_a1;
auto a2;

v_a1.blinker_ein(10); // Compilerfeher
a2.blinker_ein(10; // Okay

v_a1.blinker_aus(10); // Okay
a2.blinker_aus(10); // Okay

...

Warum, muss wie in diesem Beispiel gezeigt, die Methode "blinker_ein" 
mit Volatile deklariert werden und was macht "Volatile" mit der Methode?

Vielen Dank im Voraus.

Schöne Grüße

Martin

[Johann L. (gjlayde)]

auto ist ein Schlüsselwort. Nenn die Klasse anders (aber nicht if, else, 
for, typedef, volatile, unsigned, main oder so, das sind alles 
Schlüsselworte in C/C++).

[Martin (Gast)]

Okay, danke, dummer Fehler.

class car
{
public:
uint16_t geschwindigkeit;
uint16_t farbe;
uint16_t gewicht;

uint16_t blinker_ein(uint16_t var);
uint16_t blinker_aus(uint16_t var) volatile;
}

...

int main(void)
{
volatile car v_a1;
car a2;

v_a1.blinker_ein(10); // Compilerfeher
a2.blinker_ein(10; // Okay

v_a1.blinker_aus(10); // Okay
a2.blinker_aus(10); // Okay

...

[Johann L. (gjlayde)]

Es fehlt ein

#include <stdint.t>

uint16_t etc. werden durch stdint.h zur Verfügung gestellt.

[Peter II (Gast)]

Martin schrieb:
> int main(void)
> {
> volatile car v_a1;
> car a2;

ich habe das gefühl das du den Sinn von volatile nicht 100% verstanden 
hast. Warum willst du hier die Variable  v_a1 volatile machen? du kannst 
sowieso nicht aus einer ISR darauf zugreifen weil sie in main lokal 
deklariert ist.

Das ganze macht nur bei globalen Variaben einen sinn. (bzw. globalen 
objekten)

[Stefan E. (sternst)]

Martin schrieb:
> Ich
> verstehe nicht, warum nach einer "volatile"-Instanziierung der Klasse
> auch die Methoden von "volatile" sein müssen, falls sie benutzt werden.

Der Code der Methode ist für alle instantiierten Objekte der Gleiche. 
Wie kann nun also dieser Code anhand des ihm übergebenen this-Pointers 
sehen, ob das Objekt volatile ist, oder nicht? Er kann es schlicht 
nicht. Mit dem volatile sagst du der Methode, dass sie "ihr" Objekt 
grundsätzlich als volatile ansehen soll. Und von einem volatile-Objekt 
kannst du dann natürlich nur volatile-Methoden aufrufen, eben weil nur 
diese von einem volatile-Objekt ausgehen und damit entsprechenden Code 
enthalten.

[Martin (Gast)]

Aber ich verseht nicht, wozu das notwendig ist, dass Methoden ihr Objekt 
als "volatile" ansehen sollen.
Geht es nicht vielmehr nur um die einzelnen Attribute (z.B. 
geschwindigkeit, farbe, gewicht), dass diese ohne Verzögerung in den 
Speicher geschrieben oder vom Speicher geholt werden sollen, damit eine 
IRQ-Routine ebenfalls darauf zugreifen kann?

Was ist so wichtig daran, dass die Metode selbst als "volatile" 
gekennzeichnet wird?

Wenn ich z.B.

#include<stdint.h>

class car
{
public:
volatile uint16_t geschwindigkeit;
volatile uint16_t farbe;
volatile uint16_t gewicht;

uint16_t blinker_ein(uint16_t var);
uint16_t blinker_aus(uint16_t var);
}

car a1;

int main(void)
{

a1.blinker_ein(10);

...

In diesem Beispiel instanziiere ich zwar das Objekt "a1" nicht mit 
"volatile", aber die drei Attribute in der Klasse selbst sind mit 
"volatile" gekennzeichnet. Auf diese Weise kann ich aus einer 
IRQ-Routine ohne Probleme auf diese Attribute zugreifen, ohne, dass das 
ganze Objekt als "volatile" instanziiert werden muss und die Methoden 
muss man auch nicht separat kennzeichnen.

Ich verstehe die Vorteile und Nachteile zwischen den beiden Beispielen 
nicht.

Entschuldigt, meine Unwissenheit, ich stehe in C++ noch ziemlich am 
Anfang.

[Läubi .. (laeubi)]

Martin schrieb:
> dass diese ohne Verzögerung in den  Speicher geschrieben
> oder vom Speicher geholt werden sollen, damit eine
> IRQ-Routine ebenfalls darauf zugreifen kann

Das hat überhaupt nix mit IRQ, Optimierung oder "verzögerungen" zu tun, 
sondern sagt einfach nur dem Compiler, dass sich die Variable außerhalb 
seines Sichtbereiches jederzeit ändern kann, oder das schreiben auf 
diese für den Compiler nicht vorhersehbare Seiteneffekte hat.

Dasd führt dann dazu, dass bestimmte Optimierungen/Änderungen nicht 
durchgeführt werden dürfen.

[daniel root (Gast)]

das ist in Analogie zum const qualifier durchgezogen

class A {
   void foo();
   void bar()const;
};

A a;
a.foo() => ok
a.bar() => ok


const A a;
a.foo(); => not ok
a.bar(); => ok

[Rrolf Magnus (Gast)]

Ist auch sinnvoll so. Dadurch können für Objekte, die volatile sind, 
auch nur Memberfunktionen, die als volatile deklariert sind, aufgerufen 
werden. Nur in denen ist auch sichergestellt, daß die Anforderungen, die 
volatile an den vom Compiler erzeugten Code stellt, auch erfüllt sind.

[Martin (Gast)]

Vielen Dank für eure Antworten!

Ich werde mich noch eingehender mit dem Thema beschäftigen, aber ihr 
habt mich mit euren Erklärungen bereits ein die richtige Richtung 
geführt.

Schöne Grüße

Martin