Talk:C Programming/Pointers and arrays
From Wikibooks, the open-content textbooks collection
Someone wrote:
Declaring an array variable without a size is equivalent to declaring a pointer
followed by a bogus example. This statement is completely untrue. One declares an incomplete array that, unless later completed, is completed at the end of the translation unit with 1 element. It takes up the space of the element. The other declares a pointer, and takes up the space of a pointer. You really should understand this stuff before trying to teach it...
It's a syntax that comes from C's predecessor B. It's still an accepted syntax for function parameters. Look:
int fn(int a[]){
a++;
return *a;
}
To really understand all this, I think it is good to describe how C evolved out of B. Without that background, lots of stuff just doesn't make sense. C sometimes gives you a "free" unary & operator when you use an array as a pointer; I'm sure that this is a major cause of beginner confusion. It makes sense once you know that arrays in B were really pointers to arrays. The arrays lost this when the language gained structs, because prior to the C++ invention of constructors there would be no way for the pointer to get initialized to point at the data. Thus we get the weird array-as-a-pointer feature that confuses people.
I think that teaching this should involve:
- generic language-neutral concepts of arrays, pointers, and strings (no code examples)
- how B did things
- the big language change
- review
- strings now const. New C99 variable-size array stuff
All through it, the oddities of pointer arithmetic will require frequent reminders. (the whole 42[array] thing, *array, and so on)
AlbertCahalan 04:45, 29 September 2005 (UTC)
Removed the casting of void* to an object pointer type. void* was introduced specifically as a generic pointer type that does not need casting; such casts are a relic from pre-ANSI C when char* was abused as the generic type. Also, removed text that stated that such a cast is necessary. While casting may seem harmless, it can mask the serious problem of forgetting prototypes for allocation functions. In addition, it simply clutters up code. One rarely sees code like "char x = (char)'x';" even though 'x' is an int, for example. The same principle should apply to pointers. -- 67.170.85.37 04:06, 3 January 2006 (UTC)
Could anybody explain me that:
typedef int (*MyFunctionType)( int, void *);
I thought typedef is used like that: typedef long int* abc; abc variable1; thx
- MyFunctionType typedef'ed to be a pointer to a function that takes two arguments (int, void *) and returns an int. Read about the syntax for declaring function pointers in C. --Spoon! 07:22, 25 July 2006 (UTC)
[edit] article style
I gotta tell you, this article is really unclear...the problem is changing the way of thinking of someone, especially if they have to wrap their minds around pointers and arrays in quick succession as the article flows. It's especially hard because my background is Java and Perl...
--168.105.118.205 11:10, 30 April 2006 (UTC)
- I agree. What is this supposed to mean? When returning a pointer from a function, do not to return a pointer that points to a value that is local to the function or that is a pointer to a function argument. WTF? Also, the nonsense examples are distracting. MEANINGFUL examples would be more helpful, even if they're slightly longer. 128.250.37.103 10:14, 23 August 2006 (UTC)
-
- It means that, since local variables are deallocated when the function returns, don't return a pointer to any of those variables, or it will be a dangling pointer. Care to rephrase it? --Spoon! 02:05, 1 September 2006 (UTC)
Just as a note, the current external link to a 'pointer cheat sheet' actually goes to a quiz, which I wouldn't describe as a cheat sheet.
[edit] merge
I suggest merging our discussion about pointers into this module C Programming/Pointers and arrays, rather than talk about them here and again in a section of another module C_Programming/Complex_types#Pointers. --DavidCary (talk) 15:21, 28 March 2009 (UTC)
