Int* foo;

int* foo;


or

int *foo;

Woah, the remake puts this to fucking shame

int *foo;

Integer foo

int * foo;

var foo

The second is more logical.

Depends. First one when writting c++ second one when writting c.

Int* foo makes more sense to me.

Only int *foo, *bar; is correct. C types are shit.

Even if you declare several int pointers on the same statement?
int* foo, *bar;

That's why
int *foo;
makes more sense for me even though i never declare more than one pointer in the same statement.

I dont like to do multiple declarations in a line anyways

int* is literally not an int so obviously int*

in terms of the multiline bullshit, that's only because C's grammars are fucking awful.

int *foo because pointers are attached to variable names, not types

Ur fucking trash

but the fact that its a pointer is part of the type of the variable i user

var foo : Int

int * foo;

I like the solution to Go devs came up with, putting the * in front of the type (and the type behind the variable, but that shouldnt matter).

Compiling gives the same result so use the one you like.

LOL

let foo: &i32;

int *foo; obviously, that's what K&R says

int *foo because foo is a pointer to an integer.

Which means it's not an integer, rather a pointer to an integer, therefore *int

int* foo;
This is not acceptable because what happens if you do
int* foo, bar;
Only foo is a pointer, and bar is just a regular int. For that reason the only 2 ways I find acceptable are
int *foo, *bar;
or
int * foo, * bar;

The second way may seem kind of strange, but consider the following code.
std::string const&foo, const&bar;
Kind of messy when you throw the word const in there.
std::string const& foo, const& bar;
tadah! finally something that isn't an eye sore (by C++ standards, anyways)

No, there's no such thing as an "int pointer". It's a pointer that when dereferenced gives an int.

fucking hell. yesterday i was starting to learn c from a site that throws you like a rag doll into the washing machine

i kind of understand pointers, but not really. maybe the site is just crappy or just too basic, but just don't see the purpose of pointers

learn-c.org btw

Well the compiler disagrees with you. Try doing int* foo, bar; and tell me what bar is.

Ah but it is an integer. Consider this:

* is a symbol for dereferencing. foo is a pointer. *foo is the integer that it points to.

Therefore
int *foo;

is actually logically consistent, since *foo refers to the integer stored at foo.

This

You use pointers when you need a reference but you also want it to be possible to set it to null. You use references when you don't want to copy variables around by value. There are multiple reasons why you may not want to pass in a variable by value.
1. Passing by value only gives you a copy of the variable. Any changes made to it, will not be applied to the original. If you want to alter the original you will want to pass by reference.
2. The variable may be larger than 8 bytes (4 bytes if on 32-bit architecture). If this is true, it will be costly to pass the variable by value (it will take multiple cpu cycles). A reference is always the same size no matter what is being referenced.

int* foo;
int* bar;

is the only proper answer.

tits * foo

intconst* foo (will not compile)
vs
int const* foo (does compile)
vs
int const*foo (does compile)

int
*
foo;

Using "int* foo;" is bad practice.

The reason is because of this example:

int* x, y, z;

The spacing implies that all three variables are of type int*. But that's not true -- y and z are actually of type int.

It's exactly the same kind of bad practice as writing this:


int n = a+b * c+d;


This is bad because the spacing suggests that + has higher precedence -- when in fact the * has higher precedence.

Except as already pointed out, there is no such thing as an "int pointer". Merely a pointer which happens to be pointing to the memory address of an integer.

no, the whole type is: a pointer pointing to an int. that's the type of foo and it's different from type short* or void*.
if you don't believe me, try doing pointer arithmentic with int* and then with void*

>int times foo
How about no

why the fuck would anyone write a+b * c+d. are you mentally challenged?

depends on the language.
first one in c++, second one in c.

This is proper. It's an int pointer and this notation makes that fact clear.

Also fuck declaring multiple variables in single line.

/thread

Ban C!

why the fuck would anyone write int* foo. are you mentally challenged?

Assuming this to be C, int* of course.

The compiler also has some pretty stupid ideas about operator precedence, it was just poorly designed in some places.

>Also fuck declaring multiple variables in single line.

Enjoy wasting 10 lines of space just to declare your variables nigger

Ever heard of an array? A struct? Do you declare all your vars flat? Learn2program

>The spacing implies
it doesnt. its well defined what the types of x, y and z are. just because someone would write their declaration like that and doesnt understand how the language works, is not an argument against int* foo.

>wasting 10 lines of space
It's not a competition to use the smallest possible number of lines. Readability comes first.

Oh no scrolling down!

Nooooooooo

int *foo = pleb
int* foo = patrician

By that logic there's no such thing as an int, just a series of bits that can be arbitrarily interpreted as an int

That's exactly right.

lsl in the lll was the shit

So you just redefine a bunch of words and expect people to understand anyway?

int* foo;

makes just as much sense as
int* foo, *bar;

Which makes perfect sense.

2nd one is inconsistent which is probably what most people have a gripe with. It's all just a form of autism, any C programmer will know wtf that means anyway. But for clairty's sake, you should probably newline those.

I'll have the preprocessor do that for me.

>putting your fucking temp vars in an array
Good fucking luck figuring out which is which when debugging.

So put them in new lines. It's far more readable than

int *this, *is, *a, *jackass, *way, *of, *programming, *and, *you, *touch, *yourself, *at, *night;

And we're right back at what the previous guy said about 10 bloody lines of code for declaring a few pointers.

int* this;
int* is;
int* about;
int* three;
int* times;
int* as;
int* retarded;
int* and;
int* completely;
int* pointless;

int iA, *pB;
int iC;
char * cFirst =( (char *) malloc(strlen(sz_String) +1)) ;

Try to resist the urge to vomit when reading this and I'll give you 10 bucks.

It's also more fucking readable. Lines are cheap.

typedef struct s_wow
{
>int* this;
>int* is;
>int* about;
>int* three;
>int* times;
>int* as;
>int* retarded;
>int* and;
>int* completely;
>int* pointless;
} t_kys;

t_kys just;

But you're just declaring a bunch of shit. You don't really need it to be readable as it doesn't actually do anything except reserve a few names and some space. It's kinda like includes/imports, you need them there to use the library, but the less they disturb you the better. So the one line declare makes it clear what each individual one is, yet doesn't grab unnecessary attention from non-trivial parts of code.

The only case where I could possibly see readability of declaration being useful is if you're declaring a million variables with very similar names (in which case arrays make more sense) or if you REALLY wanna spot if you forget the * somewhere, but that's not useful either as you'll just get the "integer without a cast" error anyway.

Great, you just added another layer of complexity to trivial shit, good job.

You can't write separate comments for a single line. One variable a line means you can comment the ones you feel appropriate.

>You don't really need it to be readable
Great argument.

Fool. The more readable your code, the less secure your job.

Have fun wasting your own time by deliberately fucking over your future self with poorly readable code.

>Have fun wasting your own time

You're unemployed, aren't you?

I guess it makes sense then, if the names aren't descriptive enough. I was mostly talking about declaring trivial shit though.

Though if you'd need longer descriptions it might still be better to just declare everything in a line and write up a manpage-style description underneath (normal sentences, just referring to variables as you go)

Variable declarations are not even required anymore in most modern languages, why would you care how readable they are?

You really think writing shitty code is the way to sustain a programming career?

Code quality is what separates the monkeys from engineers. Enjoy your shittiness I guess.

I see it every day at work. I wish I could post examples but they'd have my neck.

What if you are to declare variables in a single line only when they are used for the same goal?
int *pAtoJobA, *pBtoJobA;
int *pAtoJobB, *pBtoJobB;

typedef int *pInt;

pInt pi;
int i;

pi = &i;

>how to write confusing code
>by user

So long as you use that notation, sure, don't see why not, I've done that before too.

Obviosly the naming isn't so good, but my point stands.

this
/thread

int* foo, bar;
Which ones are pointers?

I think int* and int& makes a lot more sense. In the very rare occasion I have to declare a bunch of pointers in one line I have to do
int* buf1, * buf2;
If I forget a star, the compiler will catch it and I can move on with my life.

What you are describing is inconsistency. Have fun writing inconsistent code you fucking retard.
>inb4 but muh code is consistently inconsistent
into-the-trash.jpg

intN_t *foo;

Literally every single other part of my code is extremely consistent, I can assure you.

same

Go is my hasubando

tag: golang

>every single other part
>other
Just do int * buf1, * buf2; and move on with your life. For reasons stated already here it is the most consistent and readable option.

You misspelled System.Int32

Stop putting multiple variable declarations in a single line.

It looks like multiplication.

int *x, *y = 13, *z

Even with single variable declarations per line doing int* is bad form because of reasons stated here

int const pointer
int pointer

Makes sense to me

So you are advocating for
int const * foo
and
int * foo

Sure, I guess I'd be fine with that too, since it can be applied consistently without any exceptions.

int* foo makes more sense in my opinion, as it is a pointer to an int. That's the type.
Only problem is this fucks up when you do
int* foo, *bar

By that logic things like constint foo makes more sense than const int foo. Keep your key-words/characters separate.