Why are pointers in C declared as int *mypointer; when int &mypointer;

nani

>>61914111
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.

>>61914111
Because *mypointer is an int.

>>61914111
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'.

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

>>61914261
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

>>61914111
>int *mypointer;
disgusting

int* intPtr;

is better

>>61914392

int * intPtr;

even better :^)

>>61914392

int *pointer, integer

vs

int* pointer, integer

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

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

&int pointer

makes most sense

>>61914416
>int* isn't a type

int* ptr = (int*) malloc(sizeof *ptr);

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

>>61914494
>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.

>>61914111
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.

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

>>61914111
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

>>61916280
Stfu read the thread

>>61914374
>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.

>>61914111
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.>>61914111

>>61917591
arrays and pointers are not the same you shithead

>>61917638
he didn't say that moron

>>61914210
>implying they learn C in CS

>>61914111
What would

int &&foo;

mean?
S ***id_frogposter;

>>61914392
>>61914406
>>61914416
>>61914494
Can't the janitors ban this bot.
This worse than sakurafish but I like it.

>>61914111
because it's 1969

>>61918282
rvalue reference

>>61914494
no

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

>>61918960
If you think a type like

int(*)(int)

is reasonable then you're a lunatic.

>>61914406
>uding the smiley with a carat nose

>>61919007
What would make more sense?

>>61919162

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.

>>61919199
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.

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

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

>>61919457
Do what? You mean the

sizeof *ptr

rather than

sizeof int

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

why? because you are a fucking dumbass.

>>61914111

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

>>61919395
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.

>>61914416
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.

>>61919544
> 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.

>>61919528
wut
you know pajeet as well?

>>61919652
>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.

>>61919748
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.

>>61919781
>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.

>>61916711
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);
}

>>61915945
>casting the return value of malloc
kys

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

>>61914416
>tfw D fixes this

>>61920318
>Wanting Hime-chan to kill herself
kys

>>61920353

int[2][4] arr;
arr[3][1];

D just invents new problems.

>>61920383
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);
}

>>61920362
>her

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

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

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

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

what's wrong with

std::shared_ptr<int>
 my_ptr

?

>>61922426
shared pointers are often just wasting resources

File: how-many-layers-of-abstraction-are-you-on-you-are-3409103.png (141KB, 500x609px) Image search: [Google]

141KB, 500x609px

>>61922426
One too many layers of indirection.

>>61921871
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.

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

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

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

>>61914111
Declaration follows use.

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

>>61924491
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?

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

>>61920021
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.

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

>>61924491
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

>>61921534
Learn 2 program faggot

>>61919499
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.

>>61925938

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

The combined declaration and assignment makes it look inconsistent.

>>61926102
That's the point.

>>61914111
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.

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