Which style do you prefer?

which makes more sense when its written that way right?
It's a bit misleading to leave the star next to the type in that situation.

>using anything but the middle one

Attached: 1541861257754.png (618x618, 29K)

i bet you also write the following shit code:
i = ++i + i++ + ++i;

int *ptr; is the only one which makes sense in the context of C and C++ syntax.

If you use any of the other styles you either do not know the language you are using or you are a disingenuous faggot.

int* ptr;
The fact that it's a pointer is more relevant to the type than the variable name. If I'm looking at the type of some variable, you can bet your ass I want to know if it's a pointer or not, so I want that information to be as close to the type as possible.

int* ptr and not declaring multiple vars in a single line to avoid the confusion.

Maybe there's a good technical reason to do it otherwise, maybe it's just down to preference, either way it's just the easiest format for my brain to parse.

"int* ptr" because it's a pointer of a type and easier to skim read.

I'd agree with this if it meant both of these were pointers, but since they're not, I prefer the first one.

>is the only one which makes sense in the context of C and C++ syntax.
I mean, I agree with even though I prefer the first style.
// These two sort of make the distinction better
int* p; // Declare (integer pointer) p
*p; // De-reference (integer pointer) p

// You can also think of it like this
// Here the type declaration is (int) or (int*)
int a = 0;
int* p;

// Here int is like a data modifier (short int) or (int *)
short int a;
int * p;

// This sort of reads off awkwardly
int *p;

Most of the people that struggle to learn pointers get confused because they don't even realize pointers are there own type. They just think of it as integers that you can assign and modify to other variables. Also, inb4 "hurr durr only retards don't understand pointers user".

I prefer the correct style.

int a; // means a has type int
int v[20]; // means (v[expr]) has type int
int *p; // means (*p) has type int
int f(int a) {} // means ( f(a) ) has type int
int (*f)(int a); // means doing (*f)(a) has type int, in other words, f is a pointer to a function from int to int

Btw this is why K&R C had the fugly function declaration:
int foo(a, p)
int a;
char *p;
{
// ....
}

Because foo(int a, char *p) isn't an expression. foo(a,p) kept the TYPE expression; motif for declarations.

>int *p; // means (*p) has type int
Everyone has their own way of rationalizing it but like I said, p isn't an integer and shouldn't be treated like one so I find it doesn't read as well.

/thread. C was for better or worse (mostly all worse) designed with the explicit intent that variable declaration syntax would ape derefererencing/indexing syntax.

I can empathize with you desire to make C saner than it actually is, but you're a retard who just wants to muddy the waters by pretending the grammar is something it is not.

auto ptr = operation();
I hope you all don't create uninitialized variables.

Caution big dick man coming through

typedef int* intRef;
intRef x;

Imagine using pointers in 2018.

this
if you're actually typing * as part of a declaration you're doing it wrong

int* ptr;

My reasoning:
I think of the 'type' as being a 'pointer to an int'

People who do middle should be beaten.

so you geniuses are already on the std::experimental::observer_ptr train then?
or do you have some other notation that better expresses the semantics of a non-owning but redirectable reference?

I don't use pointers

its called rust bro...

if you understood Rust at all, you'd already know that dealing in raw/non-owning pointers is 'unsafe' territory, at which point why the fuck bother talking about Rust at all.

/* cause int_pointer is the type and should be grouped together */
int* ptr;

Using a language without pointers

>I can empathize with you desire to make C saner than it actually is, but you're a retard who just wants to muddy the waters by pretending the grammar is something it is not.
Did you not read the entire post? I said I prefer the first style despite all that. Everyone can rationalize it their own way and I don't force it on anyone. No one has taught pointers using grammar either. Not sure why you have to screech when you don't like another way of looking at something.

Yes, because like xyz_cast(), naming specific intended semantics instead of using a catch-all results in generally safer, more readable code.

template
using ptr = T*;

ptr ptr_to_int;
const ptr const_ptr_to_int;
ptr ptr_to_const_int;
const ptr const_ptr_to_const_int;

ptr *int

additionally has the advantage that

ptr ptr_to_int, also_ptr_to_int;

ever since C++11 came out, a lot of codebases just use T * for this, with everything else either smart_ptr or T &.

Bar is an integer, but I'm going to go out on a limb and disagree with K&R. Effectively, you've declared two variables of different types (one int pointer, one int) on the same line, and I think that's stupid.

Yes so do I, but that's still convention rather than something with an explicit name

int* foo,
* bar;

lets be honest here, having to declare pointers is dumb and should be removed from C

int *p because in a C handled the way god intended pointers aren't types

I prefer the first one, and I also agree with

The unsafe block is literally the best thing about the language. It allows for hardware-level manipulation of memory but keeps the effects of those actions constrained in a well-defined manner.

Last one is the only acceptable one, pointers should be considered another data type not just an int

>pointers should be considered another data type
They are...

>declaring multiple variables on the same line

You know i++ and ++i do slightly different things right?

> Using 2 spaces
None of them are correct.
int *ptr;

Last. The asterisk is inherent to the datatype, so it should be on the left with the type. Or at least thats how I imagine it

neither

Top when I'm writing C, bottom when I'm writing C++. Why? C++ Core Guidelines lul.

Last one.

int* foo,
bar
Hm....