What do people find difficult about C pointers? [closed]

Answer 1

When I first started working with them, the biggest problem I had was the syntax.

int* ip;
int * ip;
int *ip;

are all the same.

but:

int* ip1, ip2;  //second one isn't a pointer!
int *ip1, *ip2;

Why? because the "pointer" part of the declaration belongs to the variable, and not the type.

And then dereferencing the thing uses a very similar notation:

*ip = 4;  //sets the value of the thing pointed to by ip to '4'
x = ip;   //hey, that's not '4'!
x = *ip;  //ahh... there's that '4'

Except when you actually need to get a pointer... then you use an ampersand!

int *ip = &x;

Hooray for consistency!

Then, apparently just to be jerks and prove how clever they are, a lot of library developers use pointers-to-pointers-to-pointers, and if they expect an array of those things, well why not just pass a pointer to that too.

void foo(****ipppArr);

to call this, I need the address of the array of pointers to pointers to pointers of ints:

foo(&(***ipppArr));

In six months, when I have to maintain this code, I will spend more time trying to figure out what all this means than rewriting from the ground up. (yeah, probably got that syntax wrong -- it's been a while since I've done anything in C. I kinda miss it, but then I'm a bit of a massochist)

Answer 2

Proper understanding of pointers requires knowledge about the underlying machine's architecture.

Many programmers today don't know how their machine works, just as most people who know how to drive a car don't know anything about the engine.

Answer 3

Here's a pointer/array example that gave me pause. Assume you have two arrays:

uint8_t source[16] = { /* some initialization values here */ };
uint8_t destination[16];

And your goal is to copy the uint8_t contents from source destination using memcpy(). Guess which of the following accomplish that goal:

memcpy(destination, source, sizeof(source));
memcpy(&destination, source, sizeof(source));
memcpy(&destination[0], source, sizeof(source));
memcpy(destination, &source, sizeof(source));
memcpy(&destination, &source, sizeof(source));
memcpy(&destination[0], &source, sizeof(source));
memcpy(destination, &source[0], sizeof(source));
memcpy(&destination, &source[0], sizeof(source));
memcpy(&destination[0], &source[0], sizeof(source));

The answer (Spoiler Alert!) is ALL of them. "destination", "&destination", and "&destination[0]" are all the same value. "&destination" is a different type than the other two, but it is still the same value. The same goes for the permutations of "source".

As an aside, I personally prefer the first version.

Answer 4

Pointers (along with some other aspects of low-level work), require the user to take away the magic.

Most high level programmers like the magic.

Answer 5

I think one reason C pointers are difficult is that they conflate several concepts which are not really equivalent; yet, because they are all implemented using pointers, people can have a hard time disentangling the concepts.

In C, pointers are used to, amoung other things:

• Define recursive data structures

In C you'd define a linked list of integers like this:

struct node {
  int value;
  struct node* next;
}

The pointer is only there because this is the only way to define a recursive data structure in C, when the concept really has nothing to do with such a low-level detail as memory addresses. Consider the following equivalent in Haskell, which doesn't require use of pointers:

data List = List Int List | Null

Pretty straightforward - a list is either empty, or formed from a value and the rest of the list.

• Iterate over strings and arrays

Here's how you might apply a function foo to every character of a string in C:

char *c;
for (c = "hello, world!"; *c != '\0'; c++) { foo(c); }

Despite also using a pointer as an iterator, this example has very little in common with the previous one. Creating an iterator that you can increment is a different concept from defining a recursive data structure. Neither concept is especially tied to the idea of a memory address.

• Achieve polymorphism

Here is an actual function signature found in glib:

typedef struct g_list GList;

void  g_list_foreach    (GList *list,
                 void (*func)(void *data, void *user_data),
                         void* user_data);

Whoa! That's quite a mouthful of void*'s. And it's all just to declare a function that iterates over a list that can contain any kind of thing, applying a function to each member. Compare it to how map is declared in Haskell:

map::(a->b)->[a]->[b]

That's much more straightforward: map is a function that takes a function which converts an a to a b, and applies it to a list of a's to yield a list of b's. Just like in the C function g_list_foreach, map doesn't need to know anything in its own definition about the types to which it will be applied.

To sum up:

I think C pointers would be a lot less confusing if people first learned about recursive data structures, iterators, polymorphism, etc. as separate concepts, and then learned how pointers can be used to implement those ideas in C, rather than mashing all of these concepts together into a single subject of "pointers".