Why are pointers in C declared as

Why are pointers in C declared as
int *mypointer;
when
int &mypointer;
makes more sense?

nani

Please finish your C homework before complaining

>le groundbreaking revelation of a cs 101 student
you must be so proud

C++ was made to make no sense. Read the manifesto.

Because *mypointer is an int.

Because the type doesn't match up in your recommendation. '*' is indirection, so working backwards the declaration 'int *mypointer' says that the variable 'mypointer' when dereferenced will be of type 'int'.

seriously though, wouldn't it make more sense to label the variable as an address when it's effectively representing one?

this makes some sense, but I think that if you declared a variable as
int &variable;
it implies that the value stored at the address labeled 'variable' is an integer

>int *mypointer;
disgusting
int* intPtr;
is better

int * intPtr;

even better :^)

int *pointer, integer
vs
int* pointer, integer

int* isn't a type fucker, stop treating it like one

Irrelevant, because putting multiple statements in a single line is stupid.

&int pointer makes most sense

>int* isn't a type
int* ptr = (int*) malloc(sizeof *ptr);

I think *int makes more sense, but close enough.

>putting multiple statements in a single line is stupid.
no u

Isn't it like.

Int* x is a pointer to the address of x.

So, 0x1234 -> 0xABCD then

0xABCD | The int variable.

I don't know shit though.

An int which is the address of a location?
What a scandalous waste of numerals

int square(int x) { return x*x; }

int main(int argc, char **argv)
{
int x;
void (*fptr)() = (void(*)()) square;
x = ((int(*)(int)) fptr)(x);
}

Don't let anyone ever tell you that C's type system makes sense.

see Basically, C declaration syntax was apparently in some way designed to reflect the usage. A retarded idea.

how does &mypointer make more sense? clearly the most logical choice would be some form of the letter P.

How about who fucking cares what it is because none of this pedantic shit matters you autistic freaks.

Desu, ptr is best

Stfu read the thread

>wouldn't it make more sense to label the variable as an address
A pointer isn't an address, it takes up bytes of memory just like any other variable.

Because the creators of C had the retarded idea that it would be cool if pointer and array declarations looked the exact same as their dereferencing/indexing calls.

Everyone with half a brain realizes it was stupid, but it's just something you have live with for the language.

arrays and pointers are not the same you shithead

he didn't say that moron

>implying they learn C in CS

What would int &&foo; mean?
S ***id_frogposter;

Can't the janitors ban this bot.
This worse than sakurafish but I like it.

because it's 1969

rvalue reference

no

How doesn't this make sense. It takes a while, but it makes perfect sense...

If you think a type like int(*)(int) is reasonable then you're a lunatic.

>uding the smiley with a carat nose

What would make more sense?

int(int)
Regular functions are function pointers when they get compiled down, the problem is that C had no notion of constness before C++ added it.

No that'd make no sense. You call a function through its address and it'll return the type. It's not an int, it's an address that'll result in an int.

This implies that it's actually an existing int in memory, which is flat out false.

sure it's a variable, but whatever is in that variable is always an address

is it possible to do it on one line like this? Wouldnt the compiler complain?

Do what? You mean the sizeof *ptr rather than sizeof int

you declare ptr on the left side of equal and use it on the right side.

why? because you are a fucking dumbass.

Because to get the int from mypointer you have to dereference it

Whether you're calling through a function pointer or a baked-in function, you're still doing the same thing. Push the args onto the stack or into registers (depending on calling conventions) and jump to the address of the function.
The idea of a function pointer being a special form is wrong to begin with, but C's syntax makes it ugly on top of that. Take int(*)(int) for example, what's the star there for? What's being dereferenced? Some invisible unnamed variable I guess.
The split between the forms you need when you're doing declarations (declare as used) and the form you need when you're doing a cast (name the type) makes any sufficiently advanced C ugly and inconsistent and leads to people following awful conventions like int* foo to try to achieve some semblance of consistency.

I saw this gem at work:
int buffer, *p_buffer = &buffer;
set_buffer_function(p_buffer, sizeof(buffer));

And p_buffer was never used again.

> What's being dereferenced
The specific function, in C called by its name which is used to identify the function itself.

I agree that it's ugly but it's right and it's understandable enough. Nothing much will give you verbosely as much flexibility with functions as this syntax. int(int) isn't right because it undermines the fact that it's an address and not an actual function that's inserted right there. with int (*)(int), you can understand that you need an address, and that you can give it through the function name because that's what usually goes in the first parentheses.

wut
you know pajeet as well?

>it's an address and not an actual function that's inserted right there.
That's exactly what happens with a real function though.
void foo() {}
void bar() { foo(); }
// foo's address is baked into bar to jump to, not the function body itself
Unless you're compiler's inlining ofc.

I see the name as the address from the start, as this is how you treat it everywhere else. I wouldn't treat a function as a regular variable either.

>I see the name as the address from the start, as this is how you treat it everywhere else.
Of course, that's exactly what it is. You call a function and a function pointer in the same way.
>I wouldn't treat a function as a regular variable either.
The difference is one of immutability.
void foo(void) {};
void (*bar)(void) = foo;
void baz(void)
{
bar();
foo();
}

bar is mutable. bar is a variable at a particular offset in the executable and all calls to bar occur by jumping to the address stored at this offset.
foo is immutable. Rather than looking up the address in the foo "variable", the value of foo can be fixed into the program at all call sites and the "canonical" foo can be elided. Or the whole body of the function may be inlined at the callsite.

I think it's easier to understand my point if you compare it to how other constants work.
static int x = 0;
static const int y = 0;
int do_sth()
{
return x + y;
}
The offset of x in the program will be stored in do_sth because its value can't be known until it is used, but the value of y can be placed immediately within the function body because it won't change. The "canonical" y can be removed from the binary completely if it's placed directly at all those use sites.

This can be made sane by having the type after the declaration, e.g.:
fn square(x: isize) -> isize { x*x }

fn main() {
let fptr: fn(isize) -> isize = square;
let x = fptr(1);
}

>casting the return value of malloc
kys

I'm illustrating a point, but you're a faggot if you don't write in the common subset anyway.

>tfw D fixes this

>Wanting Hime-chan to kill herself
kys

int[2][4] arr;
arr[3][1];
D just invents new problems.

I like Rusts array notation, desu
fn main() {
let arr: [[i64; 4]; 2] = [[1, 2, 3, 4], [5, 6, 7, 8]];
assert_eq!(arr[1][3], 8);
}

>her

Fucking brainlet, people like you should never bring shame upon C.

This post reeks of someone who doesn't understand what a pointer is.

You're even more retarded than the fucking shithole language you're defending

You can dereference a pointer, you cannot dereference an address.

what's wrong with std::shared_ptr
my_ptr?

shared pointers are often just wasting resources

One too many layers of indirection.

That's more or less just the compiler keeping you from doing something stupid

For example, I can declare a void pointer, fill it with a specific address, pointer cast, and dereference the pointer into whatever type I assume is at the address.
This is essentially just saying "dereference the address as whatever type is specified"

I don't really see why C doesn't let you do something like this directly from the address directly, other than to keep the programmer from doing something stupid since it would only be useful in very limited contexts.

An address is an integer constant in C, so you still have to cast it to pointer type before you can dereference it.

Isn't preventing you from doing stupid things the only reason type systems exist to begin with?

Yes, and that's why C's type system is as cheap and flimsy as they come.

Declaration follows use.

If you evaluate the expression (*mypointer), the type returned is an int.

Sometimes you must name the whole type, e.g. in a cast. Why could the language not be completely consistent and name the entire type in the type specifier rather than using this declarator crap?

writing "int" half a dozen times when only one is needed is stupid.

This post.

Except the C standard says you can take the address of a const variable. A compiler *may* optimize it into a binary constant if you never take the address of it.

That's more of a way to distinguish pointers from integers than any sort of necessity

If I were to declare a pointer and initialize it, it looks like the following:
int *pointer = &variable;
yet if I were to assign the value stored at the pointer to something I would use
*pointer = variable+1;

which is completely counter intuitive

Learn 2 program faggot

no, pointers are always the same size regardless of the data type the pointer points to. the compiler knows this and inserts the appropriate value.

int variable = 7;
int *pointer = NULL;
pointer = &variable;
*pointer = variable;

The combined declaration and assignment makes it look inconsistent.

That's the point.

It makes perfect sense. The * when used in the unary context is the deference operator, meaning it will access the value located at the memory address. So you using the * when declaring a variable, you are telling the computer to access the variable at the address and store the value you declare it. The & when used in the unary sense means to get the address of the value and not the value, so declaring it as such and not providing an address doesn't really make sense.

It's not counterintuitive once you get past that though.