"type* ptr" or "type *ptr"

[KarlisRepsons]

Yes, it's indeed irrelevant for compilers I know about if I choose

type* ptr;
// or
type *ptr;

type& ref = refv;
//or
type &ref = refv;

But still I struggle a bit to pick one of the ways for my style, where I have no style to adopt. If we could sum up the relevant logical arguments about it, would any of the variants be more logically right?

[m4ster r0shi]

I'd use DataType *ptr; because *ptr's type is DataType, and DataType& ref; because if I wrote DataType &ref; it would seem like &ref's type is DataType, which is not, since &ref is just the address of the object...

[KarlisRepsons]

Hmm, that is if you view things solely from the point of view of meaning of * and & operators in relation with addressing...

On the other hand, it would depend on what one wants to see in variable declarations in a simple form: type name or variable name. It would seem better to see variable name in plain, which would arrive at "type* ptr", but thats just a quick and personal opinion. If we would discard the previous idea of m4ster r0shim, nothing but that preference would remain? Or ther's something more of real importance?

[moorecm]

I prefer to leave a space on both sides of the operators when declaring a type but if they are used in the context of dereferencing or getting the address of I place them adjacently.

const char * s;
s = &s2;
cout << *s;

[Galik]

I always use this way:

type* tptr;
type& tref;

I feel it makes more sense to think of the pointer as being part of the type. So the type can be an 'int' or an 'int pointer' which is different. Or it can be an 'int reference' which is different still. And so I would write an int pointer as "int*" and an int reference as "int&".

This works for anonymous parameters where there is no identifier to attach the symbol to:

int func(const char*, const std::string&);

Which makes me feel that the symbol (* or &) is part of the type more than the identifier.

[1yR4jE8b]

Type name; //and
Type* name;

are 2 completely different types. Type* is a pointer type, and Type is well....a Type. I don't see why the * should be seperated from the typename when it is an integral part of it.

[Disch]

I'm with Galik, darkestfright, etc.

The * is part of the type, therefore I put it with the type, not with the var name.

[guestgulkan]

Each man to his own.

I prefer putting it next to the identifier name.
That way I can do:

int *p1, *p2; which is more consistent

[firedraco]

I prefer putting it next to the type name.

[helios]

Odd. I thought the majority here preferred it next to the variable name, based on the code I've seen.

[chrisname]

It depends. For example, is a C-string a "char pointer" or a "pointer to char". If it's a "char pointer" then the asterisk goes next to the type because a pointer is a type in it's own right; if it's a "pointer to char" the asterisk goes next to the variable name because the pointer is an attribute of the variable.

Technically, it's the latter. If char* was it's own type, then you couldn't do this:

char* str, /* This is a pointer to char */
      chr; ./* This is just a char */

Also, putting it next to the variable name is more consistent:

char* str = malloc(4096);
/* ... */
*str = 0;

The inconsistency is in the pointer dereference. The asterisk is next to the variable name there, but not when declaring the variable.

Having said that, I'll always put the asterisk(s) by the datatype. I think it looks neater.

@helios,
I thought that too.

---

inb4 holy war, <flamesuit>, etc.