Can someone explain to me which one to use and why?

Can someone explain to me which one to use and why?
int *ptr;
int* ptr;

There's no difference. It's just convention.

I prefer int* ptr, cause it bugs me that *ptr dereferences in one context, but int *ptr means a pointer to an int.

int * ptr;

Wrong brainlet. It means exactly the same in assignment statements. * means "contents of" & means "address of"

int y = 4;

int * ptr x = &y:
"The contents of integer x equals the address of y"

int z = *x + 1
"integer z equals the contents of x plus 1"

>contents of
No, * is the dereference operator.

I mean int * x

Try making a program with this:
int* a, b;
and see what happens.

This is what bogs me, consider the following:
int * ptr = &x;
Should this be that the contents of ptr = x, or should int* be considered a sort of type?

You shouldn't use raw pointers at all in C++.

Allowing multiple declarations in the same statement was a huge mistake IMO.

I am learning c++ right now, care to explain why? :)

typedef int * int_ptr;


You will save yourself much grief.

Smart pointers famalam.

Not him, but smart pointers exist for a reason.

>You will save yourself much grief.
typedef std::shared_ptr int_ptr;

even more so

From C++ primer:

>Some symbols, such as & and *, are used as both an operator in an expression and
as part of a declaration. The context in which a symbol is used determines what the
symbol means:

>int i = 42;
>int &r = i; // & follows a type and is part of a declaration; r is a reference
>int *p; // * follows a type and is part of a declaration; p is a pointer
>p = &i; // & is used in an expression as the address-of operator
>*p = i; // * is used in an expression as the dereference operator
>int &r2 = *p; // & is part of the declaration; * is the dereference operator

>In declarations, & and * are used to form compound types. In expressions, these same
symbols are used to denote an operator. Because the same symbol is used with very
different meanings, it can be helpful to ignore appearances and think of them as if
they were different symbols.

fucked up the greentext, cause I copied from the pdf, but oh well

not everyone should state their opinion

And not everyone should be let near code at all, but hey.

int *ptr;

C's notion of declaration syntax matching the dereferencing/access syntax for arrays and particularly pointers was a retarded design choice, but it's better to not try to pretend statements are something other than what they really are.

prefix de/referencing operators were a mistake.

Golang doesn't have this problem.

C++ is a shit language for shit devs.

To the type int* ptr, because it's a pointer type
int* x, y; doesn't work because C inventors can't into grammars.

This. Also, combined indirection and implied memory type types were probably a mistake.

Go was literally created because google's """""""""""""""engineers""""""""""""""" were too retarded to use C++. Go is a neutered version of C++ that does nothing new. Anything Go can do, C++ can do better.

>muh microservices

C++ is too hard for pajeets and women and someone tought it was a good idea to put quota everywhere, real men had to innovate...

Those engineers have PhDs and are responsible for Plan9 and multiple implementations of C and C++.

Only cucks use C++

>Those engineers have PhDs and are responsible for Plan9
Which explains why they thought include statements with github URLs without any version control was a good thing and why they regressed 20 years of type safety by relying on object collection casting which was outdated even in Java 4

>Those engineers have PhDs
That doesn't say anything.
>and are responsible for Plan9
A great point against them.
>and multiple
One very simple.
>implementation of C
ftfy

yeah, shitty example.

anybody with half a brain with intention of having an int and an int pointer is going to put them on separate lines.

>Plan9
>Having to go through 8 plans before getting something that works

You shouldn't use raw pointers in C++.
They do not have a default destructor and will thus lead to memory leaks.

>Sup Forums-tier debaters think they know better than google-employed PhDs
classic

>They do not have a default destructor and will thus lead to memory leaks.
#include
void foo(int* a)
{
*a += 2;
}

int main()
{
int i = 3;
foo(&i);
printf("%d\n", i);
return 0;
}


There's no memory leak unless you call new, user.

You can still do nasty shit with smart pointers. Like double deletion.

Neither Rob Pike nor Ken Thompson have a PhD you fucking idiot.

I prefer the second. Therefore the type of 'ptr' reads 'int pointer,' rather than the name of 'ptr' reading 'pointer ptr'.

I mean, as far as the compiler is concerned they are different. Conceptually they do the exact same thing.

int * p = &x;

Fill the bytes on the stack pointed to by p with the address of x

int y = *p

Assign y to the bytes on the stack pointed to by p (which is x)

Convention, but consider this

int *ptr1, *ptr2;

How do you properly represent this the other way? You don't. That makes above correct.

>How do you properly represent this the other way?
Like this, you fucking mong

int* ptr1;
int* ptr2;


Multiple declarations in the same statement is confusing and error prone, for the exact reasons mentioned in this thread.

Only error prone if you are an idiot.

Not an argument.

None of the most commonly used code styles allow it, but by all means, go ahead and be a hipster contrarian just because you learned C two months ago.

What if I want to have a nullable reference?

std::ref , but preferably in combination with std::optional

All your padded room nanny state languages are only making it harder on everyone. Trying to lower the barrier to entry only results in poorer code from less competent people.

Oh, cool. And when you reference these pointers, do you use ptr1, or *ptr1?
int* is the variable's type, so separate it you klang.

>coding standards = padded room nanny state
Go tell that to Linus and see what he replies.

kek, yes, avoiding multiple declarations on one line is lowering the barrier for entry. Those kinds of elite skills are just too much for the average programmer.

you use ptr1 to access it as a pointer and *ptr1 to access the value of it, just like you should.

>calling someone brainlet
>being wrong
k

Wow, you imperative programmers are disgusting with your types.
FP is a much purer paradigm.

You speak of coding standards and newer languages so I can see you can't see the simple problem.

Let me insert an example that I can tell you will instantly dismiss with some green text. That is the only way you will be able to refute it because I am right.

SomeLongPoorlyNamedRogueClass a;
SomeLongPoorlyNamedRougeClass b;

Both are valid but they are not the same object are they? You've just inserted a coding error that would not have existed with a comma.

this same thread everyday stop. just stop.
it int *ptr; and pretty much everyone agrees. stop.

We are talking about a language that uses imperative concepts after all. Pointers do exactly what they say they do.

Both are only valid if you have a class SomeLongPoorlyNamedRogueClass, and another class SomeLongPoorlyNamedRougeClass, which would be retarded.

Unless you mean it avoids typos, which is also a pretty dumb reason.

Don't spell badly idiot.

>You speak of coding standards
Yes
>and newer languages
No I don't, I'm speaking of fucking C you massive idiot.

K&R, Allman, GNU-style, Linux kernel coding format... They all recommend NOT using multiple declaration on the same line.

>Both are valid but they are not the same object are they? You've just inserted a coding error that would not have existed with a comma.
What the fuck are you on about?

int a, b;


is the exact same as

int a;
int b;


because of how the comma operator works.

You don't need pointers unless you're a stupid idiot using imperative languages.
Seriously, why would you even want mutable data structures.
No side effects.
monad

>Neither are misspelled

Unemployed Haskell fag detected.

One uses the memory of the objects size and the time it takes to duplicate and destroy it. The other takes only the size of a pointer and the time it takes to access it. You are kidding yourself if you think time and memory are still not important.

TYPE (NIGGERTYPE), POINTER :: NIGGERNAME

Excuse me I'm working at facebook on haxxell.
AMA

Apples newest language Swift still uses pointers. They have tried to hide it as much as possible but they are still there. Swift is very close to C. Closer to C than Objective-C is.

I'm a Haskell chef at Wendy's. 400k a year. AMA

>apple
>Using any language by the above named faggot-fest
They don't employ engineers, they employ bendergineers.

Hi my name's Simon Peyton Jones and I like memes (After all, I created one hahaha!)
AMA

Will functional programming get me pussy?

>bendergineers have contributed to FreeBSD
>bendergineers have made clang/llvm
>bendergineers are basically responsible for the most popular UNIX OS today
>bendergineers have ported (their) UNIX to a fucking mobile phone

int* ptr because it's clear that you're assigning a pointer that points to an int.

I'd then use *ptr to dereference the pointer and directly manipulate the int that it points to.

Not on its own. you have to invoke the POONTANG () monad.

I have contributed to FreeBSD and Clang as well. Want to fight about it?

>he still doesn't understand pointers
You're a fucking faggot. * in C and C++ is used for declaring AND dereferencing pointers.

>I have contributed to FreeBSD and Clang as well. Want to fight about it?
That makes you a bendergineer enabler.

Fucking shitty languages.

>reddit-tier shitposter thinks PhDs develop software

Complete retard here, does
foo(int* a)
take a reference to an int as a parameter or the data acquired by dereferencing a pointer to an int?

then don't lecture others about it, faggot

Why would you declare and instantiate a class on the same line anyway?

Reference to an int.

You'd call the function like this:

int i = 3;
foo(&i);

Since C++ also has references, I will avoid using the word reference in my explanation.

void foo(int* a)


Declares a function foo that takes an int POINTER as argument. The pointer is passed by value,

void foo(int* a)
{
a = 1001; // this modifies the pointer (aka variable that holds the address/reference)
}

void bar()
{
int i = 3;
foo(&i); // pass address/reference of i
// i here is unmodified, foo only modified the variable that holds the address (the pointer)
}


However, a pointer can be dereferenced using the dereference operator


void foo(int* a)
{
*a = 1001; // this dereferences the pointer and modifies the value (at the address contained in a)
}

void bar()
{
int i = 3;
foo(&i); // pass address/reference of i
// i here IS modified, foo modified the value pointed to
}

Actually, I'm retarded. That is how you call it, but it's not a reference you're passing. You're passing the address. The & has different meanings depending on context.

In C, addresses and references are the same. In fact, the specification uses the term "reference" when talking about address contained in a pointer.

Fuck, ok. I think I understand pointers (for the most part) but the whole using the asterisk for dereferencing and declaring pointers is still completely autistic.

this

Sounds like you have been learning the wrong languages. C languages are and will always be the best languages regardless of how intellectual you think your boutique language is.

What's a reference if it's not just another term for memory address?

This is the * operator argument we had in the thread all over again. See the section I posted from C++ primer. They mean different things in different contexts.

In C++, it is essentially syntactic sugar for a pointer with additional constraints.

In C, addresses and references are the same.

>will

can

>something that has been around for 40 years

You can go deeper, you can have a pointer to another pointer int **ptr2;

You can have a pointer to a function that returns a pointer to a function that returns a pointer pointer pointer array of functions, if you want.

My bad, you were talking about C specifically. Did not know that.

Explain to me how reference variables like "int& foo" aren't superflous when you already have pointers.

No worries, it's an honest mistake. This is a C++ thread after all.

>Explain to me how reference variables like "int& foo" aren't superflous when you already have pointers.
References have additional constraints, that allow both optimisation and type safety:
1) they aren't nullable
2) you cannot do pointer arithmetic on them
3) you can't reassign references

In modern C++ dialects, you can even do rvalue reference magic.

because you don't have to confuse pajeets with your asterisks.

the point was that someone would try to declare two int pointers and declare a pointer and an int