Clarifing Pointers the Experimental Way

[Ben Bowen]

Today I just decided to clarify my long-lived ambiguous sense of pointers, the experimental way. I once understood them very well through trial/error experience; however I have long since forgotten many key-notions of C++, due to a period of programming inactivity.

Now to set things straight for myself:

extern "C"
{
	// IO
	void printf (const char*, ...);
	void puts (const char*);
	int getchar ();
}

void Apple (long int &a)
{
	a = 100;
}

void Banana (long int *b)
{
	*b = 200;
}

int main ()
{
	long int n = 67;

	printf("n %i.\n", n);

	Apple(n); // 'n' is a variable, but it is referenced in the argument already, so Apple() can change 'n' without (&n).
	printf("n %i.\n", n);

	Banana(&n); // Here, I have to use the reference operator to point to 'n', (&n).
	printf("n %i.\n", n);

#if 0
	// Wrong
	long int* x, y; // 'y' won't be a pointer, even though this is written as-if each label should be a pointer. That's not true.
#endif

	// Right
	long int *x, *y; // Its best to always use the form '*label' because its just more sensible. As we now know, 'type* label, label;' won't automatically make all labels be a pointer.

	x = new long int;
	y = new long int;

	Apple(*x); // Redundant illustration. De-referencing a pointer to use in a reference... lame.
	Banana(y); // Banana() works directly with pointers. No redundance.

	printf("x %i.\n", *x); // Need to dereference.
	printf("y %i.\n", *y); // Need to dereference.

	delete x;
	delete y;

	getchar();

	return 0;
}

I'm also planning to do a few other C++ experiments. But they'll regard much more complicated mechanisms, being much less common and probably more critical to performance, object-size and robustness. At least they'll be about more interesting problems than this ancient ambiguity that every serious C++ programmer should understand by now.

[cire]

On line 25 it would be more accurate to say n is passed by non-const reference to Apple, so Apple may change n.

On line 28, "Here I have to use the 'address of' operator to supply the location of n to Banana."

On line 37, "I prefer to use the form '*label'" =)

[Ben Bowen]

Thanks for the suggestions. I'll remember your corrections.

[andywestken]

One way to avoid issues with code like long int* x, y; is to adopt the one variable declaration per line rule.

To me, this is not really right

	long int *x, *y; // Its best to always use the form '*label'
// because its just more sensible. As we now know, 'type* label, label;'
// won't automatically make all labels be a pointer.

	x = new long int;
	y = new long int;

This is!

	long int* x = new long int;
	long int* y = new long int;

Andy

PS I also follow the "always initialiaze all variables rule", which is easier
with one declaration per line.

[Gaminic]

But not always a possibility, e.g. member variables.