There is no need to teach people to use undefined behaviour (eg. by telling them all pointers are the same size). That's not simplifying things; It's making things worse. That's like teaching someone all liquids are the same, and bleach can be used in place of water. If people made an effort to read and understand the standard, they would surely learn how to write portable C or C++ code. How else are they going to learn, if not by reading? Closing their eyes and blindly mashing at the keyboard, hmmm?
I think for the level of this tutorial, its fine. There's nothing wrong with simplifing things - if all we did was say read the standard, nobody would learn C or C++.
Precisely. That is why I suggested reminding students of the relationship between object and value. value = value; doesn't make sense. &a is a value, not an object. That's all it takes to cover this problem.
Most people would automatically assume they could do &a = x;
Yannbane: I would like to quote again from the standard, section 184.108.40.206 point 3: Except when it is the operand of the sizeof operator, the _Alignof operator, or the unary & operator, or is a string literal used to initialize an array, an expression that has type ‘‘array of type’’ is converted to an expression with type ‘‘pointer to type’’ that points to the initial element of the array object and is not an lvalue.
This is relevant for two reasons:
1. It explicitly states that the sizeof, _Alignof and &address-of operators function differently for array expressions than pointer expressions, and thus a pointer is not an array.
2. It demonstrates the use of the words "pointer to type" in the context of expressions that aren't modifiable. I think it's accurate to use the term "values" in this context. Is this type of expression "just another variable, which can contain a memory address of any other variable or object", as you wrote? If not, then that is an inaccurate description of the term "pointer".
In addition to point 2, consider the return value of malloc: "The malloc function returns either a null pointer or a pointer to the allocated space." (n1570.pdf, section 220.127.116.11).
Is a null pointer a "variable which can contain a memory address"? What about the return value of malloc, eg. malloc(42)? Is that a "variable which can contain a memory address of any other variable or object"? It doesn't seem difficult to reiterate the relationship between objects and values, and state that pointer objects can store pointer values.
The standard seems to give the impression that:
i. A pointer value may or may not point to an object. For example, &x points to x, but null pointers do not point to objects.
ii. An address is a pointer value that points to an object. Thus, &x is an address but null pointers are not.
In summary, it is appropriate to refer to &x as either a pointer (implying "pointer value") or an address. It is not appropriate to refer to &x as a "variable which can contain a memory address of any other variable or object".
Edited by object, 06 January 2013 - 10:26 PM.