Talk:Reference (computer science)

Archived discussions

/Archived January 16 2006

New revision

I moved back stuff like pointer and smart pointer. I believe that the article then can be devoted to mention more about the basic idea--a reference as an object refering to another object. I hope the new organization or the organization as used to be works better. Let me know if you have some thought. -- Taku 01:31, Nov 11, 2003 (UTC)

Internal/external storage

While this topic has close ties with references, in that references are the device that enables external storage, it seems like it shouldn't merit taking up such a large proportion of the article. Then again, where else could it go? I'm not sure.

Derrick Coetzee 00:52, 10 Jan 2004 (UTC)

Address analogy

Personally I found the reference quite good.My girlfriend even read and understood it and since most programmers know what a reference is the analogy is directed quite effectively to the people most likely to visit the entry...new programmers and non-technical staff. Tim Garnett 11:46, August 1, 2006

I have a problem with this section. I think it is a little too lengthy and looks like a tutorial, which is unsuitable for an encyclopedia. I think saying like a memory address and other means provide indirect access to objects should suffice to explain what references are. It may not be enough for some, but that has to be the limitation of a general encyclopedia. This is the same case that we don't expect readers to know how to do real analysis by reading articles in wikipedia. Any idea? -- Taku 04:46, August 6, 2005 (UTC)

Yeah, too lengthy might be the case certainly. The analogy may be overextended. I'll try to strip it down to a few main points. I just wanted to add something to get across the main ideas behind a reference for people new to programming, and how it relates to familiar real-world ideas. Perhaps more examples would serve better than a more extensive example. Deco 08:47, 6 August 2005 (UTC)[reply]

I've parred it down somewhat, so that it's at least on par with the other sections. This section could be moved to a less prominent place in the article, if that would help - I placed it at the beginning since it seems like a newbie would start there. Deco 09:08, 6 August 2005 (UTC)[reply]

Excuse me, but I wrote the original Pointer Analogy before it moved to this location.I wanted to add on some of the points raised esp. with regard to newbies :

Mapping the Telephone No. to Address, as both need to be stored in paper/variable or memory/register respectively.
Mapping the * operator to the act of Dialling a phone no.
Mapping the levels of indirection by using pointer to pointer with the indirect phoning i.e I phone someone who phones someone till I actually connect to the person I want. I observe that the singly linked list example is given. Giving the pointer to pointer example as above would be helpful I feel ( ***ptr is like a point-to-point connection )
Keep the explanation more visual oriented to make it more intuitive (learning styles and all).

My original intention was to supply a small image instead of the lengthy explanation. I'd be glad to rewrite/redraw the whole topic with your inputs. Could you give some pointers (pun intended) on this topic. Finally, please overlook formatting errors. I'm still catching up on that. -- Guruduttmallapur 08:57, 21 February 2006 (UTC)[reply]

Confusing statements

Pointers of pointers

In the section on language support, the following statement is made in regards to Java, C#, and Visual Basic:

In those managed languages, the references are actually pointers of pointers of the referred data.

This statement is mangled at best, and I believe not just confusing, but also incorrect (although since I can't be sure what it is trying to say, correctness is difficult to ascertain.) Does pointers of pointers mean pointers to pointers (handles)? If so, this isn't correct, at least not for Java. The language does not specify the mechanism used for managing memory, but certainly the vast majority of JVMs don't use handles.

In fact, I'm not sure that you can group these three languages together in regards to their use of references. -- Doug Bell (talk/contrib) 09:57, 16 January 2006 (UTC)[reply]

I would rearrange this by adding a discussion of handles and mentioning that some implementations of some languages use them. Deco 18:18, 16 January 2006 (UTC)[reply]

Two-step pointing

The sentence following the pointers of pointers sentence above is:

In C/C++, the reference concept of managed languages means two-step pointing.

It seems that the author is attempting to talk about indirection through handles, but I'm not familiar with the terminology two-step pointing. Since I'm pretty sure I'm well above average in familiarity with this subject, this either needs rewording or some explaination.

Also, the reference concept of managed languages might be clearer as the concept of references in managed languages, but again I'm not even sure that's the meaning the author intended.

The whole language support section seems a bit rough. -- Doug Bell (talk/contrib) 12:28, 16 January 2006 (UTC)[reply]

Agreed, I don't like how this is worded. It's fine to describe specific behaviour of Microsoft's implementation of .NET, but we should word it as such and in particular not attempt to view C/C++ which long predated .NET from the perspective of .NET. Deco 18:17, 16 January 2006 (UTC)[reply]

Mid-step pointers

Continuing the string of obscure references (pun not intended), the sentence following the two-step pointing sentence above is:

The Garbage Collector is the sole actor that can directly access the mid-step pointers, which cause the opacity.

The terminology mid-step pointer is apparently referring to the hidden opaque pointer in a handle. The form in which this term is used requires the term to stand on its own, but I can find no other reference to mid-step pointer.

I concur that this is confusing. Deco 00:18, 17 January 2006 (UTC)[reply]

Actually after reading opaque pointer this seems to have nothing to do with, well, what I would normally think of as opaque pointers. It seems to be describing some kind of data hiding technique for classes. Deco 01:20, 17 January 2006 (UTC)[reply]

I agree that the description of opaque pointer does not match your description of opaque (below) as it applies to references. Opaque as discussed in opaque pointer is referring to the opacity of the referenced object, whereas opaque as applied to "reference" in the article is referring to the opacity of the reference value. Nevertheless, the term "opaque" refers to information hiding in both cases. Simply replace opaque pointer with pointer in my original statement to correct it. I think this discrepency in the usage of "opaque" just further illustrates the point that the meaning of opaque as used in the article needs to be defined. -- Doug Bell (talk/contrib) 19:39, 17 January 2006 (UTC)[reply]

Sorry, I know what you meant. I agree that clarification and/or rewording is needed. Deco 21:23, 17 January 2006 (UTC)[reply]

Opaque and much more opaque

The article uses the term opaque in three places—once discussing smart pointers as opaque data structures, once discussing opaque references in Lisp and, finally once discussing much more opaque references in Java, C# and Visual Basic. There needs to be some definition of opaque here, particularly what it means to be much more opaque. (Note that I added a Wikilink to opaque pointer at the first reference, but this still doesn't make the use of the term clear in this article.)

I would have attempted to fix some of this up, but a) it wasn't clear to me what the author of those passages was trying to say, and b) because for a small article, this article has a long history of being editted. Discussion welcome. -- Doug Bell (talk/contrib) 09:57, 16 January 2006 (UTC)[reply]

To say that a reference is opaque is to say that the number of possible operations on it, particularly dangerous operations, is restricted. The vague phrase much more opaque simply means many less such operations are possible. I guess it does need to be fixed up. Deco 10:04, 16 January 2006 (UTC)[reply]

Pointers: a little historical perspective

I have removed "The C programming language introduced the pointer ..." Pointers in programming languages are at least as old as ALGOL. --75.15.154.154 05:59, 4 July 2007 (UTC)[reply]

Direct or indirect access?

Please rewrite the first paragraph so that you do not confuse 'directly' and 'indirectly'. —Preceding unsigned comment added by 203.222.167.145 (talk) 08:02, 3 August 2009 (UTC)[reply]

The point that must be emphasized is that a reference does not need any significant lookup or computation. This is the feature that distinguishes a reference from a key or indetifier. I tried to change "directly access" to "have immediate access" to avoid the alleged confusion with "indirect access", but then noticed that this change creates another confusion with "immediate operands" where a computer instruction contains the data rather than its address.
So I am changing it back to "direct access". On second thought, the claimed direct/indirect confusion does not seem to exist. "Direct addressing" usually means that the instruction contains a reference to the data, so the word "direct access" is appropriate in that context. In architectures where memory is addressed only through registers, one may say "register addressing", so "direct access" causes no confusion there either. Finally, "indirect addressing" is when one has a refernce to a memory location that contains a reference to the data; so the first memory access is "direct", the second one "indirect". All the best, --Jorge Stolfi (talk) 13:44, 3 August 2009 (UTC)[reply]

Pointers vs. Opaque References

Great article! Could be improved by explaining the difference between pointers and opaque references like those of Java and C#. This is a good explanation: Pointers vs References — Preceding unsigned comment added by 50.181.81.149 (talk) 21:33, 2 May 2015 (UTC)[reply]

Internal and external storage

See Talk:Linked_list#Internal_and_external_storage. Dcoetzee 11:37, 4 March 2010 (UTC)[reply]

Formal representation is flawed

The given formal representation is deeply flawed:

"If we have a set of data D, any well-defined (single-valued) function from D onto D ∪ {null} defines a type of reference, where null is the image of a piece of data not referring to anything meaningful."

First, why is the map from D to D? The set of keys is completely different from the set of data. Also, why should this map be "onto" (i.e. surjective)? First, there may be data objects that are not reachable through reference, for whatever reason. Second, even if each object had a key, saying "onto D ∪ {null}" means that there must always be a key that yields null, i.e. that the set of keys must contain invalid references. Why should that always be the case? — Preceding unsigned comment added by Vog (talk • contribs) 09:18, 23 February 2017 (UTC)[reply]

Then, it continues with:

"An alternative representation of such a function is a directed graph called a reachability graph. Here, each datum is represented by a vertex and there is an edge from u to v if the datum in u refers to the datum in v. The maximum out-degree is one. These graphs are valuable in garbage collection, where they can be used to separate accessible from inaccessible objects."

Here, again, keys and data objects are mixed in a strange way. Also, it ignores data composition: If there are only data objects that are either no reference or a single reference (as stated by "the maximum out-deegree is one"), you couldn't build that many useful data structures. So either composition is modeled in the graph, then the given graph needs to be extended to be e.g. a bipartite graph of data objects and keys (references). Or, composition is assumed to be hidden within the vertices (which seems to be the case here), but then a datum may contain multiple references, so the constraint "maximum out-degree is one" needs to be removed.

Either way, the graph definition as given here is flawed. Vog (talk) 10:25, 23 February 2017 (UTC)[reply]