On 02/16/2013 08:16 AM, Ben Davis wrote:
On 16/02/2013 15:19, Jacob Carlborg wrote:
On 2013-02-16 15:13, Ben Davis wrote:
As for 'volatile', there's some info at
http://dlang.org/deprecate.html#volatile about how it used to be
available for marking statements as 'do not optimise field accesses'.
The corrective action listed there is to use 'synchronized' instead. So
probably your best bet is to use 'synchronized' blocks wherever you
access the variables that you know are meant to be volatile.
Hope that helps :)
If you're interfacing with C you should just remove the volatile
statement/keyword.
"There is no volatile type modifier in D. To declare a C function that
uses volatile, just drop the keyword from the declaration."
http://dlang.org/interfaceToC.html
That's only telling you how to declare a C *function*, not a C struct
(or global). While you'll probably get away with it in practice, I think
dropping it from a struct is technically unsafe (and may break as a
result of future compiler optimisation improvements) unless you back it
up with the 'synchronized' strategy.
I was going to suggest __gshared, but for struct members it implies
static, so it's not what you want. There doesn't seem to be a way to
make a struct member 'volatile' for the purposes of interacting with C
(which seems to be a gap in the C support).
Thank you. Since "volatile", IIUC, is suppose to mean "This think can
change without warning, and for no reason that you'll be able to see.",
I think perhaps I should just use a normal variable of the correct size,
and comment it as "/**< DON'T USE THIS VARIABLE*/". My only qualm about
this was that the compiler might write the current value of
the structure back over the structure parameter. (Well, actually since
I don't intend to use ANY of the variables in the struct, but just pass
it to another C routine in the same library, the opaque pointer solution
works well in THIS case. But I was worried about what to do if I needed
to change one of the variables.)
Perhaps this is worrying unreasonably...it's definitely worrying about
things I don't yet need to deal with.
