Declaring multiple object pointers on one line causes compiler error

sf::Sprite* re_sprite_hair, re_sprite_body, re_sprite_eyes;

Does not declare 3 pointers - it is one pointer and 2 objects.

sf::Sprite* unfortunately does not apply to all the variables declared following it, just the first. It is equivalent to

sf::Sprite* re_sprite_hair;
sf::Sprite re_sprite_body;
sf::Sprite re_sprite_eyes;

You want to do:

sf::Sprite *re_sprite_hair, *re_sprite_body, *re_sprite_eyes;

You need to put one star for each variable. In such cases I prefer to keep the star on the variable's side, rather than the type, to make exactly this situation clear.

In both C and C++, the * binds to the declarator, not the type specifier. In both languages, declarations are based on the types of expressions, not objects.

For example, suppose you have a pointer to an int named p, and you want to access the int value that p points to; you do so by dereferencing the pointer with the unary * operator, like so:

x = *p;

The type of the expression *p is int; thus, the declaration of p is

int *p;

This is true no matter how many pointers you declare within the same declaration statement; if q and r also need to be declared as pointers, then they also need to have the unary * as part of the declarator:

int *p, *q, *r;

because the expressions *q and *r have type int. It's an accident of C and C++ syntax that you can write T *p, T* p, or T * p; all of those declarations will be interpreted as T (*p).

This is why I'm not fond of the C++ style of declaring pointer and reference types as

T* p;
T& r;

because it implies an incorrect view of how C and C++ declaration syntax works, leading to the exact kind of confusion that you just experienced. However, I've written enough C++ to realize that there are times when that style does make the intent of the code clearer, especially when defining container types.

But it's still wrong.

This is a (two years late) response to Lightness Races in Orbit (and anyone else who objects to my labeling the T* p convention as "wrong")...

First of all, you have the legion of questions just like this one that arise specifically from the use of the T* p convention, and how it doesn't work like people expect. How many questions on this site are on the order of "why doesn't T* p, q declare both p and q as pointers?"

It introduces confusion - that by itself should be enough to discourage its use.

But beyond that, it's inconsistent. You can't separate array-ness or function-ness from the declarator, why should you separate pointer-ness from it?

"Well, that's because [] and () are postfix operators, while * is unary". Yes, it is, so why aren't you associating the operator with its operand? In the declaration T* p, T is not the operand of *, so why are we writing the declaration as though it is?

If a is "an array of pointers", why should we write T* a[N]? If f is "a function returning a pointer", why should we write T* f()? The declarator system makes more sense and is internally consistent if you write those declarations as T *a[N] and T *f(). That should be obvious from the fact that I can use T as a stand-in for any type (indeed, for any sequence of declaration specifiers).

And then you have pointers to arrays and pointers to functions, where the * must be explicitly bound to the declarator¹:

T (*a)[N];
T (*f)();

Yes, pointer-ness is an important property of the thing you're declaring, but so are array-ness and function-ness, and emphasizing one over the other creates more problems than it solves. Again, as this question shows, the T* p convention introduces confusion.

Because * is unary and a separate token on its own you can write T* p, T *p, T*p, and T * p and they'll all be accepted by the compiler, but they will all be interpreted as T (*p). More importantly, T* p, q, r will be interpreted as T (*p), q, r. That interpretation is more obvious if you write T *p, q, r. Yeah, yeah, yeah, "declare only one thing per line and it won't be a problem." You know how else to not make it a problem? Write your declarators properly. The declarator system itself will make more sense and you will be less likely to make mistake.

We're not arguing over an "antique oddity" of the language, it's a fundamental component of the language grammar and its philosophy. Pointer-ness is a property of the declarator, just like array-ness and function-ness, and pretending it's somehow not just leads to confusion and makes both C and C++ harder to understand than they need to be.

I would argue that making the dereference operator unary as opposed to postfix was a mistake², but that's how it worked in B, and Ritchie wanted to keep as much of B as possible. I will also argue that Bjarne's promotion of the T* p convention is a mistake.

In C++11 you have a nice little workaround, which might be better than shifting spaces back and forth:

template<typename T> using type=T;
template<typename T> using func=T*;

// I don't like this style, but type<int*> i, j; works ok
type<int*> i = new int{3},
           j = new int{4};

// But this one, imho, is much more readable than int(*f)(int, int) = ...
func<int(int, int)> f = [](int x, int y){return x + y;},
                    g = [](int x, int y){return x - y;};