Volatile is Evil
bluebytesoftware.com
Volatile is Evil
1–10 of 23 posts
Re: Volatile is Evil
#2It is very annoying that 'volatile' means different things in different languages. Inexcusable that Microsoft should unilaterally change the meaning of 'volatile' in their C++ compiler, adding yet another #ifdef into everyone's code.
Re: Volatile is Evil
#3It is very annoying that 'volatile' means different things in different languages. Inexcusable that Microsoft should unilaterally change the meaning of 'volatile' in their C++ compiler, adding yet another #ifdef into everyone's code.
when talking about different things in different languages I always shudder and have to think about "static", going from java to c++ this was horrible
Re: Volatile is Evil
#4It is very annoying that 'volatile' means different things in different languages. Inexcusable that Microsoft should unilaterally change the meaning of 'volatile' in their C++ compiler, adding yet another #ifdef into everyone's code.
Both C and C++ defines volatile as something like "Access to volatile objects are evaluated strictly according to the rules of the abstract machine." (exact wording from some old draft of C++0x I have here) with C explicitly noting that "What constitutes an access to an object that has volatile-qualified type is implementation-defined." (ISO 9899 6.7.3.6). So there is not many to say about what volatile means without knowing exact implementation (and implementation should document what volatile exactly means).
I don't see what Microsoft could do to unilaterally change meaning of something that is almost completely implementation-defined.
Re: Volatile is Evil
#5Java defines it in a very useful way. It's identical to an AtomicReference, but without any test&set semantics. Anything other than that seems pretty dangerous.
Personally I find the issue with volatile is that it's quite subtle unless you're looking at the declaration. I tend to use AtomicReference even if I don't need test&set, unless it's extremely performance critical, but it almost never is. The inner loop variables don't need to be volatile.
Re: Volatile is Evil
#6It is very annoying that 'volatile' means different things in different languages. Inexcusable that Microsoft should unilaterally change the meaning of 'volatile' in their C++ compiler, adding yet another #ifdef into everyone's code.
when talking about different things in different languages I always shudder and have to think about "static", going from java to c++ this was horrible
'static' in C is the worst - it has 2 different meanings within the same language. Does anyone know the reason for this confusing design decision?
Re: Volatile is Evil
#7Earlier quoted context omitted.
when talking about different things in different languages I always shudder and have to think about "static", going from java to c++ this was horrible
'static' in C is the worst - it has 2 different meanings within the same language. Does anyone know the reason for this confusing design decision?
Reason for this is that static actually does exactly same thing in both cases: defines global variable without externally accessible name and makes it accessible in enclosing scope. (exact standarteese being "internal linkange with static storage duration")
Re: Volatile is Evil
#8It is very annoying that 'volatile' means different things in different languages. Inexcusable that Microsoft should unilaterally change the meaning of 'volatile' in their C++ compiler, adding yet another #ifdef into everyone's code.
Both C and C++ defines volatile as something like "Access to volatile objects are evaluated strictly according to the rules of the abstract machine." (exact wording from some old draft of C++0x I have here) with C explicitly noting that "What constitutes an access to an object that has volatile-qualified type is implementation-defined." (ISO 9899 6.7.3.6). So there is not many to say about what volatile means without…
I'm not so sure that your reading of the standard is correct. From n1256.pdf, the essentially unchanged and freely available draft of the C99 standard:
(5.1.2.3.2): Accessing a volatile object, ..., or calling a function that does any of those operations are all side effects...
(5.1.2.3.3): In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object).
It does not look like this allows an implementation complete freedom in deciding what constitutes an "access". In fact, I'm pretty certain that 'volatile int i; i;' is required to access i exactly once. (There are plenty of optimizer bugs in this area, but these are bugs.)
(Note that the above has nothing to do with threads and everything with memory-mapped devices. Perhaps you were thinking of threads? These are not part of the C standard, though.)
Re: Volatile is Evil
#9Earlier quoted context omitted.
'static' in C is the worst - it has 2 different meanings within the same language. Does anyone know the reason for this confusing design decision?
Reason for this is that static actually does exactly same thing in both cases: defines global variable without externally accessible name and makes it accessible in enclosing scope. (exact standarteese being "internal linkange with static storage duration")
It's actually quite remarkable the number of places a single keyword can be used. We have
* Static functions in C
* Static variables in C
* Static members in C++
* Static instance variables in Java
* Static methods in Java
Re: Volatile is Evil
#10Earlier quoted context omitted.
Both C and C++ defines volatile as something like "Access to volatile objects are evaluated strictly according to the rules of the abstract machine." (exact wording from some old draft of C++0x I have here) with C explicitly noting that "What constitutes an access to an object that has volatile-qualified type is implementation-defined." (ISO 9899 6.7.3.6). So there is not many to say about what volatile means without…
I'm not so sure that your reading of the standard is correct. From n1256.pdf, the essentially unchanged and freely available draft of the C99 standard: (5.1.2.3.2): Accessing a volatile object, ..., or calling a function that does any of those operations are all side effects... (5.1.2.3.3): In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate…
(6.7.3.6): What constitutes an access to an object that has volatile-qualified type is implementation-defined.
That seems to me like giving 'complete freedom in deciding what constitutes an "access"'. Or almost.
Actually, chapter 4.10 of GCC 4.4 manual documents how is this defined by GCC and explicitly states, that discarding result of read of volatile object does not always cause access to such object.