3 ms·

> "Both programs also contain another value of 43. This is the constant that was written directly into the program." (p. 29) — I have no idea what this means.

> "Both programs also contain another value of 43. This is the constant that was written directly into the program." (p. 29) — I have no idea what this means. > I believe that the author thinks that integer constants are stored somewhere in memory. The reason I think this is that earlier there was a strange thing about a "constant being written directly into the program." Later on page 44 there is talk about string constants and "setting aside memory for constants." I'm wondering now… Yes, most of the book is wrong. In this example, the author probably also presented this idea in a wrong way. But the author is correct for having the idea that "constant being written directly into the program" (by the compiler!) and "integer constants are stored somewhere in memory", they are correct and make perfect sense. Of course the integer constants and string constants are all allocated and stored somewhere in memory (or somewhere that can be mapped as memory). They are usually known the text segment and data segment. > …(remember, the array name becomes a pointer when used without the subscripting brackets)" > "…while a pointer, as always, is a special variable that holds the address of a memory location." (p. 57) — Still wrong, but slightly less wrong. Good enough IMHO. It is true that an array "name" is a pointer to its base address.

goldenkey 8y ago
A constant can simply be part of the actual assembly instructions in the code segment. Depending on what type of constant and how large it is, it might just be inlined instead of using a memory load. Shared use can also be a compiler heuristic, a large constant used 100 times is more likely to be a shared reference instead of inlined.
- bcaa7f3a8bbc 8y ago
  Accurate. They don't have to be inside the data segment - they can simply be part of the actual assembly instructions. But more or less, it means the constant is "being written directly into the program". If "program" refers to the object code unambiguously, I don't think this expression is problematic per se.
caf 8y ago
It is true that an array "name" is a pointer to its base address... No, it's not. It is true that an expression of array type, when it is not the subject of either the unary-& or sizeof operators, evaluates to a pointer to the array's first element. sizeof array gives the size of the whole array, not the size of a pointer. &array gives the address of the whole array, not the address of a pointer.
- bcaa7f3a8bbc 8y ago
  I've programming under the useful but wrong assumption, that > array[x] and *(ptr+x) is completely equivalent, so array and ptr is equivalent. until now. Thanks for the clarification.
  - 8xde0wcNwpslOw 8y ago
    Strictly speaking, the initial part of your assumption is not wrong, but the later conclusion is. array[x] and *(array+x) are indeed equivalent for any identifiers 'array' and 'x' (assuming one of those evaluates as a pointer value, and the other as an integer value; otherwise the code is incorrect). In fact, in this context an actual array is not subject to either unary-& or sizeof operators, so it evaluates to a pointer value, fulfilling the precondition. This is why "array subscription" also directly works with pointers (i.e. "ptr[x]"), and from the equivalence above follows one of the common useless facts that you can swap the identifiers (i.e. "x[array]"). (This comment is probably confusing enough without saying that "(&array)[x]" is valid code too, but isn't the same thing as those before.)

goldenkey 8y ago

A constant can simply be part of the actual assembly instructions in the code segment. Depending on what type of constant and how large it is, it might just be inlined instead of using a memory load. Shared use can also be a compiler heuristic, a large constant used 100 times is more likely to be a shared reference instead of inlined.

bcaa7f3a8bbc 8y ago
Accurate. They don't have to be inside the data segment - they can simply be part of the actual assembly instructions. But more or less, it means the constant is "being written directly into the program". If "program" refers to the object code unambiguously, I don't think this expression is problematic per se.

caf 8y ago

It is true that an array "name" is a pointer to its base address... No, it's not. It is true that an expression of array type, when it is not the subject of either the unary-& or sizeof operators, evaluates to a pointer to the array's first element. sizeof array gives the size of the whole array, not the size of a pointer. &array gives the address of the whole array, not the address of a pointer.

bcaa7f3a8bbc 8y ago
I've programming under the useful but wrong assumption, that > array[x] and *(ptr+x) is completely equivalent, so array and ptr is equivalent. until now. Thanks for the clarification.
- 8xde0wcNwpslOw 8y ago
  Strictly speaking, the initial part of your assumption is not wrong, but the later conclusion is. array[x] and *(array+x) are indeed equivalent for any identifiers 'array' and 'x' (assuming one of those evaluates as a pointer value, and the other as an integer value; otherwise the code is incorrect). In fact, in this context an actual array is not subject to either unary-& or sizeof operators, so it evaluates to a pointer value, fulfilling the precondition. This is why "array subscription" also directly works with pointers (i.e. "ptr[x]"), and from the equivalence above follows one of the common useless facts that you can swap the identifiers (i.e. "x[array]"). (This comment is probably confusing enough without saying that "(&array)[x]" is valid code too, but isn't the same thing as those before.)