Talk:dereference

To pointer or not to pointer

I don't particularly like the current def:

to traverse a variable reference, i.e. to obtain the value stored in the memory location that is the target (r-value) of a reference (or pointer) variable

Here's my problem. There are languages like assembler that don't have pointers (or much of anything else). They have variables and memory. Yet you can still dereference things when working in those languages. It's not exactly fair, because I re-scroodled the defintion, but see the (operating system) sense of vector. I the case of operating systems I think this is even generally supported in hardware (I could be wrong), but you still talk about dereferencing the vector. I think we should either go with the foldoc definition [1]:

To access the thing to which a pointer points ...

(but I'd leave off the ...)

and ignore memory entirely or just stick sraight with a memory based definition like:

to dereference a memory location is to obtain the value stored therein in a context which interprets the value itself as the address of a memory location

(I almost want to add ", as a variable" to the end of this but that does not have to be true and thinking about it is confusing.)

I prefer the latter approach. I suppose we could have both, but the "context which interprets the value itself as the address of a memory location" basically explains the pointer concept. And the foldoc definition does not help much because if you know what a pointer is you know what it means to dereference it.

Besides, just talking about pointers (or refs) is not enough. What C programmer has not dereferenced a variable that is not a pointer? Just to write the sentence is to know that that's a legitimate use of the word 'dereference', and yet there's no pointer involved.

(I also don't like the mention of r-values, there's other ways to stick memory addresses into the storage bound to a pointer.)

Comment: The fundimental problem here is that crossing abstraction boundrys is confusing. Pointers exist as an abstraction so you don't have to deal with memory addresses, they substitute for memory addresses in languages that have them. So, either you talk in the vocabulary of pointers and references and dereferencing or you abandon the abstraction alltogether and talk straight memory. I kind of think the latter is necessary to explain pointers. Talking at both levels of abstraction at the same time means that both models have to be in your head at the same time, which makes things worse rather than better. --kop 04:28, 14 June 2006 (UTC)

Good points. All "**" dereferences in C do so without an intermediate variable. I always model those dereferences as a pair of l-r tuples, but although I can do so, such modeling is not integral to the "dereference" concept. I would remove the final "variable" in the current def., but I'm sure yours will be better. Have at it! Rod (A. Smith) 06:39, 14 June 2006 (UTC)

I like your new definition. I've tweaked it just a little to make it gloss style. I don't think I modified the meaning. Rod (A. Smith) 00:53, 17 June 2006 (UTC)

Looks great. Very pleased to have it reviewed. (I also added another meaning to multidimensional array in response to your comments there.) What is 'gloss style' and where can I read about it? I'm pretty sure there's at least 1 or two more definitions I've written that could benefit. —This unsigned comment was added by Kop (talk • contribs) 2006-06-17 01:22:26.

It's the style of definition used most frequently at Wiktionary and at most other dictionaries. It is a phrase that functions as the same part of speech as the defined term. Note that "to dereference a memory location is to obtain the value..." functions as a complete sentence, but "to obtain the value..." functions as an infinitive, which is the same part of speech as the defined term (i.e. "to dereference"). Rod (A. Smith) 02:14, 17 June 2006 (UTC)