Talk:Pointer (computer programming)

FIX ARRAY SECTION

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).

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

Old comments

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)

Edits

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)

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)

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)

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)

Good C/C++ pointer style

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)

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)

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)

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)

Wild pointers

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

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)

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)

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)

Second thoughts on move

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)

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)

C tutorial

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)

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)

pointers in C - example

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)

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

Vote to remove section on C programming.

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)

pointer diagram figure & pointer specificity

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

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)

* ((char *) 0) is nasal demons

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)

External links

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)

Performance of Pointers

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)

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)

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)

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)

Uniqueness of malloc() results

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)