Programmierer schrieb:
> volatile hat nichts mit Interrupts
> zu tun, sondern mit Compiler Optimierungen. Und das kann bei
> Multithreading relevant sein. Allerdings bin ich mir nicht sicher dass
> man volatile da überhaupt korrekt anwenden kann, und man das nicht mit
> locks/atomics machen muss...
Ja, an Multithreading hatte ich auch kurz gedacht, aber ohne konkrete
Idee was das Problem sein könnte. Compiler Optimierungen ist auch ein
gutes Stichwort, aber auch da wüsste ich nicht was konkret schiefgehen
könnte.
Tatsächlich habe ich bei meiner Nim-Version von
gtk+-3.18.1/examples/application10 mit dieser Funktion ein kleines
Problemchen -- wenn ich aber das gleichnamige Macro verwende, geht es.
Das ist eh etwas komisch, in
glib-2.43.90/gobject/gobject.h
haben wir:
1 | GLIB_AVAILABLE_IN_ALL
|
2 | void g_clear_object (volatile GObject **object_ptr);
|
3 | #define g_clear_object(object_ptr) g_clear_pointer ((object_ptr), g_object_unref)
|
Wer also nicht explizit dieses Macro zurücksetzt, wird ja wohl stets das
Macro, und nicht die Funktion verwenden.