Talk:Pointer (computer programming)

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

FIX ARRAY SECTION[edit]

The section about C arrays is totally wrong. &array and array have the same value infact, they're just different types. the visual diagram represents array as if it was a pointer, it's not exactly like that. should be fixed. —The preceding unsigned comment was added by 88.154.187.60 (talk) 02:14, 23 April 2007 (UTC).[reply]

Then fix it. Cburnett 02:56, 23 April 2007 (UTC)[reply]

Old comments[edit]

Reading this page, although it's pretty much correct, I'm not terribly fond of the approach taken. It tacitly refers to C and the Intel platform throughout, worst of all in the second paragraph, with little attention given to the variety of ways of treating pointers on other platforms or in other languages that have them, most notably assembly languages.

The statement that memory capacity is limited to pointer size is misleading and ignores segmentation, as is the statement that pointer operations are more efficient than array operations.

I also think explaining the close connection between pointers and how the underlying hardware operates would emphasize how fundamental they are. I've updated the page to strike at a few of these problems. Disagreements welcome. Derrick Coetzee 18:05, 4 Jan 2004 (UTC)

Mikkalai, please do not revert my edits without explanation. I think a mention of C++ references in the introduction is paragraph is completely out of place — I merely moved it, not destroyed it. On top of this, you reverted a perfectly good change lower down seemingly without noticing at all. I've added a statement to the intro now that I hope we can both agree on. Derrick Coetzee 05:59, 21 Sep 2004 (UTC)

You removed my perfectly valid warning about what constitutes trouble for 89% of beginner programmers, and I removed your vague and repetitive phrase about "simpler form of...". Simpler in what sense? Mikkalai 06:35, 21 Sep 2004 (UTC)
I moved your warning, not removed it. References are "simpler" in the sense that they're formally easier to reason about, because they can't do as many operations. Perhaps more restricted or less powerful is more descriptive. If you believe this confusion is a big deal, I'll leave these changes alone, but please explain yourself in the future, at least in the edit comment box, or I'm left thinking you just reverted my changes for no reason when I had a reason for doing them. Derrick Coetzee 07:32, 21 Sep 2004 (UTC)

I (Beliavsky) have added a discussion of pointers in Fortran, based on a comp.lang.fortran Usenet message by Walt Brainerd, in a thread entitled "Fortran article in Wikipedia".

I would like to known about Pointer in JAVA language.

There are no pointers in Java. See reference (computer science). Deco 01:16, 10 January 2006 (UTC)[reply]

Edits[edit]

Removed "cannot be circular" (in reference to the Haskell List implementation) because that is simply false. See this page: http://haskell.org/hawiki/TyingTheKnot You can easily make these types of lists circular in Haskell. In fact the Haskell Prelude includes a function called cycle to do that. See the function cycle in the Prelude here: http://www.haskell.org/onlinereport/standard-prelude.html

Removed "A potential advantage of the C version is that it allows for values of heterogeneous types." because it doesn't make a whole lot of sense. In order to put values of heterogeneous type in the C version you're going to need to tag your values with their types... something which Haskell supports directly and with type safety, and which C most definitely does not, so how exactly is this an advantage of the C version? 71.68.70.236 15:54, 8 January 2006 (UTC)[reply]

What I meant by "cannot be circular" was that it can't accidentally be circular; it's rather hard to accidentally give a ciruclar definition, but in the presence of mutation, accidental circularity is more of a problem. I'll clarify; you're right. Is "cannot be accidentally circular" okay?
As for heterogeneous types, various invariants could exist that would allow code to predict the types of values in a heterogeneous list. Or, with tagged structures, the tags can be part of the value rather than the list itself. I think it's better to simply call it out as a "potential" benefit. How about "A potential advantage of the C version is that it can be heterogeneously typed and used ad hoc." --Mgreenbe 21:27, 8 January 2006 (UTC)[reply]

The "accidentally circular" thing sounds better, although I'm not sure it's actually strictly true (if it's possible to do it, it's possible to do it accidentally). Maybe rather than "cannot be..." anything, just "easier to reason about" or "easier to avoid unwanted circularity" or something along those lines. I guess you're right about the C heterogenously typed thing - I didn't even think about using invariants without tagging values. Although note that in Haskell you can certainly include the tags as part of the value rather than part of the list; in fact that is the idiomatic way to do it. 71.68.70.236 01:00, 10 January 2006 (UTC)a pointer is often confused with the cursor[reply]

Haskell doesn't have pointers. This issue is relevant to references in general, not pointers in particular - let's keep any related info there. Thanks. Deco 01:13, 10 January 2006 (UTC)[reply]

Good C/C++ pointer style[edit]

When it comes to programming style, I can't decide what the best way is to define and later use pointers: 

int* myintptr;
int *myintptr;
int * myintptr;

While it is more of a cosmetical question, I'm still looking for the ultimate reason to prefer one style. What whould you say is best to use? --Abdull 14:57, 2 March 2006 (UTC)[reply]

I'd say int *myptr;, because that makes the association clearest in multiple-variable declarations, such as int *isapointer, notapointer;. —donhalcon╤ 15:42, 2 March 2006 (UTC)[reply]

I think it's just a matter of choice: I prefer int* isapointer because it makes clear that the variable is a pointer to an int. That way, I'd force myself to declare non-pointer variables in a separate line, reducing the possibility of mistakes and making it easy to see what is what just by looking at the first word on its declaration (int* versus int, int&, int**, int&*, etc.) Habbit 18:24, 2 March 2006 (UTC)[reply]

Yeah, so a lot of it comes down to the really fundamental problem, which is that C/C++ variable declarations consider pointer-ness to be part of the declarator rather than the type. —donhalcon╤ 18:33, 2 March 2006 (UTC)[reply]

It seems to me that the clearest way is int *myptr, as a shortcut for writing int (*myptr) [which is legal]. This makes the intention explicit. C doesn't have an "integer-pointer" type (which would, logically, be declared as &int myptr, i.e. declaring myptr as being of type address-of-integer [this syntax isn't allowed]). What the declaration is really saying is: let myptr be a thing which, when dereferenced (with the * operator), will be of type int. In other words, though we think "myptr is a pointer to int", what we are really writing is "*(myptr) is an int". RichardNeill (talk) 20:36, 25 April 2012 (UTC)[reply]

In C, the declarations are so interesting due to the recursive decalarator syntax to which you allude. In the C++ community, it is the widespread convention to avoid multiple declarators in one declaration statement, thereby obviating one of the aforementioned reasons for preferring the more obviously recursive form; therefore, it is not surprising that it is also the widespread convention to associate the type modifier (such as "*") as closely as possible with the type-specifier. Ergo, in the C++ community, this is preferred:
int* myintptr;
Similarly, typedef-names are often preferred for avoiding the recursive declarator syntax; for example, one could declare an identifier "g" to be of type "function of (double) returning pointer to function of (int) returning int" (that is, "g" refers to a function that takes one parameter of type "double" and that returns a pointer to a function that takes one parameter of type "int" and that returns an "int"):
int (*g(double))(int);
However, it is preferable to abandon this recursive declarator by using a typedef declaration to separate out the return type:
typedef int Func(int);
Func* g(double);
Mfwitten (talk) 05:20, 26 April 2012 (UTC)[reply]

Wild pointers[edit]

Too much code! It looks like a training manual. Alex 20:58, 28 March 2006 (UTC)[reply]

I agree. You don't need to show every bit of code. It's an example, not something for people to compile. —Andrew Hampe Talk 22:57, 4 August 2007 (UTC)[reply]
Huh? The article is called " pointers " people. You need code! —Preceding unsigned comment added by 137.30.122.155 (talk) 18:58, 10 April 2011 (UTC)[reply]
I disagree! Code is precise, and pointers are a matter of programming. As someone who programs, I find this good and correct. Mfwitten (talk) 19:51, 10 April 2011 (UTC)[reply]

Second thoughts on move[edit]

Most of Wikipedia's link to pointer mean a "data pointer", so was my move wrong? I thought it might be nice to let dog lovers have their word back. Also, a lot of teachers still use a long stick to actually "point" to a spot on the blackboard. ^_^ --Uncle Ed 15:38, 17 November 2006 (UTC)[reply]

Your move has created the confusing situation where a (category) page is the target of a redirect from the page without the category, and there's a double redirect to boot. Shouldn't this have gone to WP:RM? I'd put it there now, if I was sure what to say. --Tardis 21:05, 17 November 2006 (UTC)[reply]

C tutorial[edit]

I think we don't need to describe the C pointer syntax since Wikipedia is not a tutorial (and in any case we can't tell everything important about that in one section). — Vano 14:11, 2 November 2007 (UTC)[reply]

The difference is what is the purpose. I wrote that to demonstrate pointers. It just so happens that C is very adept at pointers, pointer arithmetic, and general uses of pointers. The point is to explain what a pointer is and one conceptualization (C) of how pointers are used. That is why it's not a tutorial on "How to use pointers in C". Cburnett 00:40, 7 November 2007 (UTC)[reply]

pointers in C - example[edit]

Interesting use of pointer in C is to get bits of type int (or real). All we do need is to declare structure as follows: struct TCislo32bit // a structure of exact size 32 bits 

                             // each b is one bit
32 bit structure

{ 

unsigned b1 : 1;
unsigned b2 : 1;
unsigned b3 : 1;
unsigned b4 : 1;
unsigned b5 : 1;
unsigned b6 : 1;
unsigned b7 : 1;
unsigned b8 : 1;
unsigned b9 : 1;
unsigned b10 : 1;
unsigned b11 : 1;
unsigned b12 : 1;
unsigned b13 : 1;
unsigned b14 : 1;
unsigned b15 : 1;
unsigned b16 : 1;
unsigned b17 : 1;
unsigned b18 : 1;
unsigned b19 : 1;
unsigned b20 : 1;
unsigned b21 : 1;
unsigned b22 : 1;
unsigned b23 : 1;
unsigned b24 : 1;
unsigned b25 : 1;
unsigned b26 : 1;
unsigned b27 : 1;
unsigned b28 : 1;
unsigned b29 : 1;
unsigned b30 : 1;
unsigned b31 : 1;
unsigned b32 : 1;

}Cislo32bit;

// first procedure is to get bits from type int via our structure. // note that this cannot be realized via cycle because of non equivalent lines.

Get bits

void DajBity32(int cislo, char *buf, int bufsiz) { 

 char *start = buf;
 char *end = buf + bufsiz;
 buf[bufsiz] = 0;          // musi byt 0 na konci
 if (bufsiz >= 32)

{ 

   buf[0] =  ((TCislo32bit *)&cislo)->b32+48;   // precast
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b31+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b30+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b29+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b28+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b27+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b26+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b25+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b24+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b23+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b22+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b21+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b20+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b19+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b18+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b17+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b16+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b15+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b14+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b13+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b12+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b11+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b10+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b9+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b8+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b7+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b6+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b5+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b4+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b3+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b2+48;
   buf++;
   buf[0] =  ((TCislo32bit *)&cislo)->b1+48;

} 

 buf = start;

}

// example of using:

Example

#include <stdin.h>

int main(void) { 

     char buf[32];
     int i = 717;
     DajBity32(i, buf, 32);
     printf(stdout, "%s", buf);   // write result

}

This can also be reversed to set exact bits of number via this structure. Other possibilities are binary operations. Janmojzis (talk) 11:37, 2 September 2008 (UTC)—Preceding unsigned comment added by 78.98.254.103 (talk) 00:30, 2 September 2008 (UTC)[reply]

Please to be stopping hurt kitty brain? --92.78.21.188 (talk) 17:21, 29 December 2009 (UTC)[reply]


Can you say, "NON-PORTABLE"? This code is garbage. There are much simpler, and portable, way to get the bits from an integral variable in C.

Vote to remove section on C programming.[edit]

This reads like a tutorial on C programming rather than an encyclopedic description of a concept. The wording and language used is at odds to that of the C standard or even the canonical text on C programming, "The C programming Language" by K&R. I think we can do better than this. I vote to discard it. 203.158.49.249 (talk) 23:42, 25 October 2009 (UTC)[reply]

pointer diagram figure & pointer specificity[edit]

I think the "pointer diagram" may be improved in 3 ways:

  1. The left column of addresses shows only 4 digits while the actual addresses on right side holds 8. Which makes the figure uselessly difficult to interpret --precisely for people who need it.
  2. The figure shows a second name "b" for the value while in the typical case (ag C pointer) there is only one name, the name of the pointer variable. This is precisely what differentiates a pointer from a (meta-)symbol, or a real reference.
  3. The figure does not show the first step of deferencing, namely the lookup for the name "a" in a symbol table, which provides for
    • the address (000000008) of the value,
    • an indication of the type of the pointer which allows the magic indirection --by interpretating the first value as an address,
    • typically, ,the type of the value itself.

(See below more comment on this.)

To sum up, there may be over the current figure: a pointer definition in pseudo-code, followed by a mini-schema showing the table lookup, which should include at least the initial address (00000008) and a sign telling that we are confronted to a pointer, not a value.

pointer specificity[edit]

This addition may usefully illustrate the pointer specificity, namely:

  • That it is an indirection compared to direct value access.
  • That it is a shortcut compared to a symbolic reference (no need for a second symbol table lookup).
 I try to illustrate what I mean below:
 * "friend: xxxxxxx" represents a table lookup for name "friend"
 * "<Person>" represents a type
 * "#00001008 --> 00000011" represents reading a value from an address
 
 ~~~ direct access ~~~
 friend: <Person> #00000008 --> 0000000011
 
 ~~~ pointer access ~~~
 friend: <Pointer> <Person> #00000008 --> #00001008 --> 0000000011
 
 ~~~ symbolic access ~~~
 friend: <Symbol> #00000008 --> person1: <Person> #00001008 --> 0000000011

--Denispir (talk) 14:51, 28 November 2009 (UTC)[reply]

* ((char *) 0) is nasal demons[edit]

It's not guaranteed to segfault, anything can happen, even if you write there. There are environments that just don't care and give you the rope, others don't even have any memory protection for the first thing. Also, the article talks about pointers as if they were ints. While this certainly explains things, and while in practice they usually are, technically they don't need to be. They could be reference numbers or something similar. AFAIR p = malloc(16)+20 is already nasal demons game over, even if you never use *p. --92.78.21.188 (talk) 17:28, 29 December 2009 (UTC)[reply]

External links[edit]

This external link is not working for me: Tutorial: C++ pointers by Alf P. Steinbach It may be a temporary down-time, so I suppose we watch it, and remove it if it does not exist any more. —Preceding unsigned comment added by 80.98.89.246 (talk) 21:50, 12 March 2010 (UTC)[reply]

Performance of Pointers[edit]

The article states that

"Pointers to data significantly improve performance for repetitive operations such as traversing strings, lookup tables, control tables and tree structures. In particular, it is often much cheaper in time and space to copy and dereference pointers than it is to copy and access the data to which the pointers point."

Could someone please explain this? רנדום (talk) 19:20, 12 March 2011 (UTC)[reply]

Copying data takes time. A pointer has one value, but the data structure to which it points might be composed of many values (and would thus take longer to copy than just the pointer); here is some C99 code to illustrate:
typedef struct { int a, b, c, d, e, f, g; } BigData;

void f(BigData x)
{
	// Sets the `a' member of the object `x':
	x.a = 3;
}

void g(BigData *x)
{
	// Sets the `a' member of the object to which `x' points:
	x->a = 3;
}

int main()
{
	BigData y;
	f(y);         // Pass by value      : Copy all 7 members of y.
	g(&y);        // Pass by reference  : Copy just the address of y.
}

Mfwitten (talk) 07:25, 15 March 2011 (UTC)[reply]

I think the point of the sentence in the article is that it is more efficient to store and manipulate pointers to objects in collections than to store and move the objects themselves. For example, an array of pointers to large objects is more efficient to rearrange (by moving the pointer elements around) than it would be to rearrange an array containing the actual large objects. — Loadmaster (talk) 17:11, 4 April 2011 (UTC)[reply]
That's the exact same explanation that I gave. However, there is actually another explanation of which there is a hint in the article:
References serve as a level of indirection: A pointer's value determines which memory address (that is, which datum) is to be used in a calculation. Because indirection is a fundamental aspect of algorithms, pointers are often expressed as a fundamental data type in programming languages...
Using pointers, a single algorithm may be used in a myriad of ways because the subroutines/subfunctions and data structures with which it works may vary; while the indirection may significantly slow down the execution of such a runtime-generic algorithm, there may still be a very a large savings in space because only the code for one algorithm need be generated for all of the uses of that algorithm. Mfwitten (talk) 23:08, 4 April 2011 (UTC)[reply]

Uniqueness of malloc() results[edit]

C implementations that permit malloc(0) to return NULL violate the principle that live pointers returned by distinct malloc() calls must compare as distinct pointers. In practice, this means that successful returns from malloc(0) must consume address space (but not necessarily actual memory). It must be legal to load these addresses into pointer registers (modulo "as if"), but not to dereference. If the fine print differs from this, there are many of us who would shoot on sight, standard or not. What's this noise about errno as a discriminator? Can I puke now? I don't hold to the maxim that all empty buckets are created equal. Zero is the greatest of all numbers, not the least. — MaxEnt 03:48, 3 April 2011 (UTC)[reply]

Values in diagram[edit]

The description below the diagram at the beginning claims that both, the memory addresses and the stored values, are hexadecimal numbers. But looking at the addresses would suggest a decimal system since 09 is followed by 10. Should the description be fixed or the diagram? Or am I just missing something (probably not)? —Preceding unsigned comment added by 109.233.64.81 (talk) 00:31, 11 April 2011 (UTC)[reply]

Yes, it appears to be a mistake. The image itself[1] (line 387) needs to be corrected, to change the 1010 to 100A. — Loadmaster (talk) 18:37, 11 April 2011 (UTC)[reply]
I personally think it would be better to change the '8' in the value to which 'a' points to a '1' or '0' and then call it a binary number (because there are 8 such numbers, so it could be a fairly standard 8-bit byte, especially given the leading zero and the fact that the other such value is already all 1s and 0s). Then, just call the address column values 'decimal numbers'; after all, many people might find decimal values easier to understand. Mfwitten (talk) 20:41, 11 April 2011 (UTC) Nevermind Mfwitten (talk) 20:55, 11 April 2011 (UTC)[reply]
I edited the SVG and the description to be more generic. Mfwitten (talk) 22:38, 11 April 2011 (UTC)[reply]

Windows's Virtual Addresses[edit]

After skimming the beginning of this article (I have no idea whether it is accurate), I have concluded that both the original and final text of this edit are incorrect or misleading; in particular:

  • Old: A process of course has access to its entire virtual address space; the remark about address 0x400000 is not really correct. In fact, a process's virtual address space is only write-protected for addresses 0-to-0xFFFF under Windows Me/98/95.
  • New: This doesn't make any sense: "Windows maps its virtual address space to start at physical location 0x00400000"; for one thing, each process has a virtual address space, and secondly, there's no way each process's virtual address space would be mapped to start at the same physical address.

I'm getting rid of the Windows example. Mfwitten (talk) 23:50, 9 May 2011 (UTC)[reply]

Move to Pointer (programming)[edit]

You are invited to join the discussion at Talk:Pointer#Mouse cursor. -- Trevj (talk) 11:02, 1 November 2011 (UTC)[reply]

History section?[edit]

Would it be appropriate to include a history section? I see Harold Lawson "is credited with the 1964 invention of the pointer.[1] In 2000, Lawson was presented the Computer Pioneer Award by the IEEE [2] for his invention." The wording of the award [ref 2] is also informative: “For inventing the pointer variable and introducing this concept into PL/I, thus providing for the first time, the capability to flexibly treat linked lists in a general-purpose high level language”.

Also, where in the TOC should this be placed? humanengr (talk) 03:47, 18 April 2013 (UTC)[reply]

Pointer diagram copied from original work of Kdakin[edit]

see page from 2009 here where the diagram originates [1]ken (talk) 05:33, 5 May 2015 (UTC)[reply]

References

  1. ^ https://en.wikipedia.org/w/index.php?title=Pointer_%28computer_programming%29&diff=324903182&oldid=324596904#/media/File:Pointers.png

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on Pointer (computer programming). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit User:Cyberpower678/FaQs#InternetArchiveBot*this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 02:41, 11 June 2016 (UTC)[reply]

cursor[edit]

Currently the "cursor" disambiguation page says "Cursor may refer to: ... Cursor, a value that is the position of an object in some known data structure, a predecessor of pointers ..." with a link to this Pointer (computer programming) page. So when I clicked on that link, I expected this page to at least mention "cursor" somewhere, and perhaps this page might discuss other predecessors of pointers (if any). Alas, currently this page doesn't seem to mention either.

What are the predecessor(s) of pointers? Is there some other more general article (perhaps reference (computer science)) that would be better for discussing the history of pointers and similar things -- cursors, handles, array index, etc.? --DavidCary (talk) 07:24, 23 January 2021 (UTC)[reply]

Dereferencing NULL in C is not implementation defined[edit]

"However, most implementations simply halt execution of the program in question, usually with a segmentation fault."

This is false. No C implementation disallows accessing the NULL pointer, because it is perfectly valid behavior for an OS to map the 0 address to physical memory. Most operating systems don't do that by default because of the safety implications, but the compiler doesn't know about that.

2A02:A44A:5C96:1:B446:3A68:C785:C0CB (talk) 05:08, 12 April 2022 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Pointer_(computer_programming)&oldid=1194080065"