4 ms·

> It’s really hard for me to see how any theology—or any text—could be any less ambiguous than any other. "Virtual base classes are instantiated in the order s

> It’s really hard for me to see how any theology—or any text—could be any less ambiguous than any other. "Virtual base classes are instantiated in the order specified by the depth-first, left-to-right traversal of the directed acyclic graph of all base classes." That is a very precise, unambiguous statement if you know what virtual base classes are. (The sentence went on to define what "left to right" meant in this context.) You don't even need to know what a directed acyclic graph is in a formal way to be able to clearly, unambiguously understand what that sentence is saying. Compare that to, I don't know, the worst sentence from your CEO's quarterly yay-us message to the company. Or the worst sentence from a politician's campaign speech, or from a political debate where they're trying to dodge the other side's point. Yes, statements can be less ambiguous than other statements. (Even in politics - compare George Bush's "Read my lips: No new taxes" with the statements many politicians make.)

rhelz 3y ago
Well…Suppose I wrote an optimizer which could—-perhaps as some kind of return-value optimization, determine that we didn’t even need to construct such an object, but we instead could just pass along the values to the caller? If I never had to create the virtual table, would it be a violation of the spec if I didn’t do it? We are so good at handling ambiguity that we don’t even notice its existence most of the time. But specs, especially specs which specify the semantics of an expression—are infinitely ambiguous as to how to that expression is actually calculated. Ideally, the spec, for c++ or another language is deliberately made ambiguous, just because it leaves room for creative interpretations—-also known as “optimizations”.
- jiggawatts 3y ago
  > If I never had to create the virtual table, would it be a violation of the spec if I didn’t do it? Generally: no. Most such specs have a phrase along the lines of “externally observable effect”. In other words, the compiler can do anything as long as the programmer or external systems can’t tell that anything is different. Processors do this all the time, reordering instruction execution but then arranging things so that it’s impossible to tell that this occurred.
  - rhelz 3y ago
    Yup. Its an interesting example of deliberate ambiguity, and how useful it can be. This is why I don't like using "ambiguous" as a term of abuse. Ambiguity isn't inherently bad. Languages are ambiguous for a reason.
    - jiggawatts 3y ago
      But this can be unambiguously defined! Externally observable effects can have specific meanings.
      - rhelz 3y ago
        I didn't quite understand that point, can you rephrase? I mean, yeah, things like specs for computer languages do define a space for ambiguity, but that space is ambiguous just the same.
        jiggawatts 3y ago
        Let's say you wrote this code: a = 2 * b + c * d; writeToDisk(a) e = b + b - a; sendToNetwork(e) Naively, you would expect the compiler to emit CPU instructions that perform the computations left-to-right, top-to-bottom. In pseudocode assembly: mul 2, b -> a mul c, d -> reg1 add a, reg1 -> a push a call writeToDisk mov b -> reg1 add b, reg1 -> reg1 sub a, reg -> e push e call sendToNetwork The externally observable effects may be considered to be the function calls. If you're dealing with I/O devices then it would be some similar specific hardware event such as writing to a GPIO register. It should be immediately obvious that the compiler can compute 2*b just once, cache it in a register, and use it to compute both 'a' and 'e', even though the formulas are different and interspersed with function calls. Similarly, it can noticed that e has a 2b-2b in its overall formula and hence eliminate some computations entirely. As long as the inputs to the functions don't change and the order of their calls aren't modified, "all is fine" and the compiler is free to do this. In fact, modern compilers can completely eliminate function calls, inlining them if they perform pure computations or have no side-effects! This is done to such a point that it makes benchmarking challenging: merely timing some computations will often take 0 time unless the result of the computation is written to the console or some similarly externally-visible destination. Compilers are allowed to this even for abstractions like virtual functions or interfaces. The JVM does this regularly. If it notices there's only a single implementation of an interface, it'll inline it, possibly eliminating the call entirely if it turns out to be a no-op.

rhelz 3y ago

Well…Suppose I wrote an optimizer which could—-perhaps as some kind of return-value optimization, determine that we didn’t even need to construct such an object, but we instead could just pass along the values to the caller? If I never had to create the virtual table, would it be a violation of the spec if I didn’t do it? We are so good at handling ambiguity that we don’t even notice its existence most of the time. But specs, especially specs which specify the semantics of an expression—are infinitely ambiguous as to how to that expression is actually calculated. Ideally, the spec, for c++ or another language is deliberately made ambiguous, just because it leaves room for creative interpretations—-also known as “optimizations”.

jiggawatts 3y ago
> If I never had to create the virtual table, would it be a violation of the spec if I didn’t do it? Generally: no. Most such specs have a phrase along the lines of “externally observable effect”. In other words, the compiler can do anything as long as the programmer or external systems can’t tell that anything is different. Processors do this all the time, reordering instruction execution but then arranging things so that it’s impossible to tell that this occurred.
- rhelz 3y ago
  Yup. Its an interesting example of deliberate ambiguity, and how useful it can be. This is why I don't like using "ambiguous" as a term of abuse. Ambiguity isn't inherently bad. Languages are ambiguous for a reason.
  - jiggawatts 3y ago
    But this can be unambiguously defined! Externally observable effects can have specific meanings.
    - rhelz 3y ago
      I didn't quite understand that point, can you rephrase? I mean, yeah, things like specs for computer languages do define a space for ambiguity, but that space is ambiguous just the same.
      - jiggawatts 3y ago
        Let's say you wrote this code: a = 2 * b + c * d; writeToDisk(a) e = b + b - a; sendToNetwork(e) Naively, you would expect the compiler to emit CPU instructions that perform the computations left-to-right, top-to-bottom. In pseudocode assembly: mul 2, b -> a mul c, d -> reg1 add a, reg1 -> a push a call writeToDisk mov b -> reg1 add b, reg1 -> reg1 sub a, reg -> e push e call sendToNetwork The externally observable effects may be considered to be the function calls. If you're dealing with I/O devices then it would be some similar specific hardware event such as writing to a GPIO register. It should be immediately obvious that the compiler can compute 2*b just once, cache it in a register, and use it to compute both 'a' and 'e', even though the formulas are different and interspersed with function calls. Similarly, it can noticed that e has a 2b-2b in its overall formula and hence eliminate some computations entirely. As long as the inputs to the functions don't change and the order of their calls aren't modified, "all is fine" and the compiler is free to do this. In fact, modern compilers can completely eliminate function calls, inlining them if they perform pure computations or have no side-effects! This is done to such a point that it makes benchmarking challenging: merely timing some computations will often take 0 time unless the result of the computation is written to the console or some similarly externally-visible destination. Compilers are allowed to this even for abstractions like virtual functions or interfaces. The JVM does this regularly. If it notices there's only a single implementation of an interface, it'll inline it, possibly eliminating the call entirely if it turns out to be a no-op.