4 ms·

It is very annoying that 'volatile' means different things in different languages. Inexcusable that Microsoft should unilaterally change the meaning of 'volatil

It 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.

Roritharr 16y ago
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
- iamaleksey 16y ago
  '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?
  - dfox 16y ago
    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")
    - alextgordon 16y ago
      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 The strange combination of C++'s namespaces and static begets static members, which almost make sense in context. But then Java stole the syntax and not the rest of the language (thank god), leading to its strange, almost contradictory usage.
      - pivo 16y ago
        In Java there are also static inner classes and static initializers (static code blocks that initialize static data)
dfox 16y ago
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.
- JoachimSchipper 16y ago
  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.)
  - dfox 16y ago
    (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.
- alextingle 16y ago

Roritharr 16y ago

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

iamaleksey 16y ago
'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?
- dfox 16y ago
  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")
  - alextgordon 16y ago
    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 The strange combination of C++'s namespaces and static begets static members, which almost make sense in context. But then Java stole the syntax and not the rest of the language (thank god), leading to its strange, almost contradictory usage.
    - pivo 16y ago
      In Java there are also static inner classes and static initializers (static code blocks that initialize static data)

dfox 16y ago

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.

JoachimSchipper 16y ago
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.)
- dfox 16y ago
  (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.
alextingle 16y ago