The Great Debate

The Great Debate

...

I prefer number 2. There's a legit justification for it too; its easy to search for the type (int*) without guessing how much whitespace is between the '*' and 'int'. UE4 also uses this style for the same reason.

int* one, two, three creates one pointer and two ints, but doesn't imply as such.
int *one, two, three correctly implies what happens, so int *ptr; is more correct

Of course C++ does everything ass-backwards, so it's generally int* ptr when writing C++

You shouldn't be declaring multiple variables on one line anyway.

int*ptr;

Whether or not you should be doing something is irrelevant to its syntactical implications

I suppose, but that's the only instance when it really matters

Again, that's not why it matters. That example just happens to illustrate what formatting choice best reflects how the language treats these constructs internally.

Yes you should you stupid idiot
int x, y, z; //x y and z are related to each other
int a; //we don't know if a b and c are related to each other
int b; //if I change this to a unsigned, does this break?
int c;

I thought C++ parsed it the same way

It does, but C++ recommends that you use the other style regardless

It's the same in C++, user.

...

My heart says
void* ptr;

but the specification says
void *ptr;

int x = 0, y = 0, z = 0;
vs
int x = 0;
int y = 0;
int z = 0;

The first one looks extremely cluttered, and you should be able to tell just by looking that x,y,z or a,b,c are related.

Which is why you can do
int x=0,
y=0,
z=0;

smart pointers

std::shared_ptr ptr;
Ah, much better!

Learn to name your variables better dipshit, declaring on the same line should NOT be how you know variables are related to each other.

If you have so many variables that you lose track of their relationships, then you should give them better names than x, y and z.

HURR DURR DON'T USE X, Y, AND Z
Learn to comprehension faggots. x, y and z are related to each other by a TYPE. That was the point of my comment

There's no fucking debate. First is the only correct option, now fuck off.

>Of course C++ does everything ass-backwards
It's not different in C++, fucking retard.
The first is correct for both C and C++.

You mean std::unique_ptr ptr;, and yes, it is much better.

>HURR DURR HAVING THE SAME TYPE IS A RELATIONSHIP DUH. WHO NEEDS READABILITY IN AN UNSAFE LANGUAGE.

t. Pajeet

First is superior. With second or third you might end up fucking up declarations.

int* var1, var2, var3
Only var1 is a pointer here. var2 and var3 are integers.

int *var1, *var2, *var3

This makes it clear and avoids that mistake.

>int* ptr
This is the only reasonable answer. Pointers are effectively a (generic) type:

T* foo == Pointer foo

>using shared
>not fully understanding memory management

How am I supposed to know what OP was using it for?

just fucking use tabularize you mongs

typedef int* pint;
pint a, b , c;

>int* ptr

the type is "pointer to int" not int

Building a shed for my bike, which color should I paint it with?

But that makes it look like the * is a part of the int, like its a new type. It sort of is, but it doesn't work like the other types. Consider the following:

int* a,b,c;

Out of these, only a is a pointer while b and c are regular integers. But putting the "*" with the "int" makes it look like they are all int pointers.

something something liking python for the wrong reasons

typedef int * pint;
pint of_beer;
hahaha

That's how it should be, but not how it actually works in C/C++

int* ptr because not being a leftist is racist.

That's an age-old mistake anybody could spot right away. Anyway you really should refrain from declaring multiple variables (especially pointers at once).
I prefer int* just because the fact that it's a pointer to an int is semantically part of the type of the variable.

>wasting courage cycles zeroing each variable
Ladies and gentlemen, this is why C is superior to C++

Who gives a Fuck

autists. So naturally, well over half of everyone here.

int* p and refrain from having multiple declarations in one statement. thanks a lot ritchie

huh?

Anything other than the top one is degenerate

>because the fact that it's a pointer to an int is semantically part of the type of the variable
Well this is not the case sadly. I would prefer to write it the way you like it, but it implies something that is not actually true. The way it is and the way it ought to be are not the same.

>int* a,b,c;
Don't you ever declare multiple parameters on one line. I've never needed this unless it's a very optimized math-heavy code like sound encoding where half of source file is written in assembly anyway. And 99.9% of the time you are not writing this.

The pointer declaration sign should be & and instead be called an adress.
>int a;
>int& b;
>b = &a;
>b is an adress of an int and it equals to the adress of the int a
It should also be either fully integrated into the type or moved to the right of the name.
>int & a, b;
>2 adresses of int
>int a&, b;
>1 adress, 1 int

Fight me C fags

Definitely int *ptr. That's how the syntax works, anything else is retarded.
t. sepples programmer

I get the feeling int* ptr fags have never needed to declare a function pointer in their lives

Can we just agree the C type syntax was a mistake?

Yes. Superior declaration syntax coming through:
*int ptr;
int[n] arr;
int -> int function_ptr;

char* my_function(void *value)
{
return (char*) value;
}

close
char *my_function(void *value)
{
return (char*) value;
}

SomeTemplateType x;

I disagree. The first has consistency that in places where it is only possible to have one type, we bind the pointer specifier to the type itself.

I think you mean:

ptr :: * int
arr :: [int n]
function_ptr :: int -> int

I use both per intention.

This means ptr is of type int pointer.
int* ptr;


This means ptr is a pointer of type int.
int *ptr;


When this is clear, double pointers suddenly become intuitive.
This means ptr is a pointer of type int pointer.
int* *ptr;

I prefer int* because that's how I read it. I also have to stop myself from writing 10$ instead of $10

I still like putting the * on the function identifier because it's forced to be there in other circumstances.
void (*foo(void))(void);

>I also have to stop myself from writing 10$ instead of $10

you read "dollars ten"?

That's true, I forgot that case.

fuck you

I think we all can agree that
int * ptr;
is for absolute brainlets

I personally use int* because I associate the asterisk with the type not the name of the variable. Its a different operator than dereferencing.

int* ptr makes more sense to me because it's part of the type, but because of how C behaves when declaring multiple variables on one line int *ptr is the correct way

typedef int * int_p;


Anything else is just wrong and opening yourself for much gnashing of teeth and wailing.

long int **my_variable

>contrived typedefs
kys yourself

this

I always thought the other ways were confusing as fuck. It's an int pointer called ptr, so int* ptr

This is how I feel too

/thread

too bad that's now how C works. You don't declare a function pointer as int(*)(int) ptr; or some retarded shit like that

see

C++ has no recommendation about style, just sepplesfags.

The first one is the only correct answer, as it creates less confusion.
int *p, q;
p is a pointer, q isn't.

>hurr durr don't use a part of the language because i want the asterisk in the wrong place

This.

...

> ::
no

Unironically 1, fampie.

Not because I want the asterisk in the wrong place, but because it's a dangerous feature by itself. There's even a specific guideline in SEI CERT C:
>DCL04-C. Do not declare more than one variable per declaration

In C: I follow OpenBSD's KNF style, thus on right
In Go: different language form ptr *int and I love this more than C/C++
In C++: Oh boy. Using clang-format on all my code, but can't decide on which style guide is better. clang-format ships 5 preconfigures:
LLVM (2space indent, opening brackets on same line, pointers to right)
Google (2space indent, opening brackets on same line, pointers to left), quite similar to llvm
Chromium probably just subtle differences from Google
Mozilla (KNF-like function notation with type and opening brackets on separate lines, buf loops etc. on same line, 2space indent, pointers to left)
WebKit - ugliest, 4space indent, inconsistent brackets for functions (without type on sep. line) and loops, pointers to left
Ofc there are more parameters (for line breaking etc.)
My dream style is 4 spaces, brackets always on same line and pointers to left, but forced myself to get used to LLVM style as a good sheep.

Yes. Languages designed by Rob Pike ALL eschew the C declarations. But then they removed the : from Go declarations, making them even worse than what they were designed to replace...

Quiz for the pajeets: what's the difference between a and b:
a) int const* foo;
b) int* const foo
Hint: no, cpp and C are not the same language.

wait, does 1st really not makes all the 3 pointers?

int* function() {
int *var

It should be the second one, but because the language is retarded it's the first one.

The second one, spaces in type names should be avoid where possible.

a: the integer that pointer points to is read-only, the pointer itself can be changed
b: the pointer is a constant, has to be initialized and won't be changed (ignoring C/C++ aliasing clusterfucks) thus will always point to the same space in memory, the underlying memory does not need to be constant

> go fmt

Correct answer for C, but yeah it's the other way around for cpp afaik.

based

>it's the other way around for cpp afaik
what in the actual fuck? Why isn't cpp already fucking dead?

Why would it?

no it's same for C++ as well

use a linter your company / project decides on. stop creating these threads.

int* ptr.

Whether a variable is a pointer or not is a characteristic of its type.

Ah, must have remembered incorrectly then, thanks.

This.

>wasting more screen space means the program is now more readable