Macht das Schlüsselwort volatile bei Klasseninstanzen überhaupt Sinn? Oder ist es nur bei Instanzen von primitiven Datentypen sinnvoll?
Wie verhält sich der Compiler (g++ 4.3 bzw 4.1) bei volatile wenn damit Objekte von Klassen deklariert werden?
Wenn ich ne (stl) map damit deklarier, hab ich das Problem, dass ich die Klassenfunktionen und -operatoren nicht mehr aufrufen kann.

Danke schon mal im voraus

Gruss
ironeagle

Hi,
kurze Frage. hab bis jetzt leider nirgends eine ausreichende Antwort finden können.

Macht das Schlüsselwort volatile bei Klasseninstanzen überhaupt Sinn?

Das ist Ansichtssache.

Oder ist es nur bei Instanzen von primitiven Datentypen sinnvoll?

...

Wie verhält sich der Compiler (g++ 4.3 bzw 4.1) bei volatile wenn damit Objekte von Klassen deklariert werden?

Gleich wie bei const, nur eben volatile statt const.
Soll heissen: auf ein(e) "const" Objekt/Referenz kannst du nur Memberfunktionen aufrufen die selbst "const" sind, und auf ein(e) "volatile" Objekt/Referenz kannst du nur Memberfunktionen aufrufen die selbst "volatile" sind.

Wenn ich ne (stl) map damit deklarier, hab ich das Problem, dass ich die Klassenfunktionen und -operatoren nicht mehr aufrufen kann.

s.o.
Da keine normale Klasse Memberfunktionen hat die als "volatile" markiert sind, kann man auch keine Memberfunktionen auf "volatile" Objekten/Referenzen aufrufen.

----

Man *kann* volatile für Klassen in der Art verwenden, dass man alles was "shared data" ist als volatile deklariert. Dadurch kann man mit normalen Memberfunktionen nichtmehr drauf zugreifen. Dann bastelt man sich einen Mechanismus der das zuständige Lock holt, und das volatile wegcastet (und der das Lock automatisch wieder frei gibt). Das Thema wurde u.A. auf der Boost mailing Liste diskutiert, kannst ja direkt dort nachlesen:

http://www.google.com/search?hl=en&q=locking_ptr+volatile&btnG=Google+Search

Genaugenommen braucht man um das zu erreichen aber kein "volatile" -- man kann genausogut eine Wrapper-Klasse (Template) verwenden. Die Version mit Wrapper-Klasse ist sogar etwas flexibler, da man u.A. in der Wrapper klasse noch mit abspeichern kann welche Mutex zuständig ist, bzw. allgemein: wie das Objekt "gelockt" werden muss.