Pointer arrays

This
Literally 2nd day of C++
Easy as shit after you take x86 assembly

>foo is a pointer
then try to assign it to something else, and see if mr. compiler agrees with your statement (spoiler alert: he won't)

Attached: ran.png (442x472, 317K)

#include

int main() {

int foo[5] = { 16, 2, 77, 40, 12071 };
int *pointer = foo;

printf("%i, %i, %i", pointer[0], pointer[1], pointer[2]);

return 0;
}

Process terminated with status 0 (0 minute(s), 1 second(s))
0 error(s), 0 warning(s) (0 minute(s), 1 second(s))

Your programming skills appear to be superior to your reading comprehension skills. I meant assign foo to something else, i.e.
int foo[5] = { 16, 2, 77, 40, 12071 };
int *something;
foo = something;

Typical Rust fag

Still essentially just syntactic sugar.

int foo[5];

is an approximate equivalent of

const int *foo = malloc(sizeof(int) * 5);

*foo == foo[0] //?

just stop please

But how will I recover the size of the array if I assign it to an *int?
sizeof(foo)/sizeof(*foo) doesn't work.

typedef them so You only need to deal with one level of array at a time

Admitted samefag but I'd like to clarify that these are very different things.
In the first case, the space for 5 integers is allocated on the stack. The memory is automatically reclaimed when that stack frame is no longer in use. The lifetime of the variable does not exist outside of the block that created it.
In the second case, the space for 5 integers is allocated on the heap. The memory is _not_ reclaimed when the stack frame is no longer on use. However, the variable holding the reference to this memory is, unless returned from the function.
Please do not confuse these two situations. While they are both technically "pointers", they behave very differently.

You can't, same if You provide it to a function. You just lose this information. That's what makes arrays on stack inconvinient. Just wrap in std::array or even vector if a lot of elements.

PS. sizeof(foo) means size of pointer, not size of array if You are confused wtf.

Store the length of the array somewhere, or use a terminating value and calculate by counting.

Please never do this. See and Retard

When you have a function that takes, say, unsigned char *foo, and you pass bar, is foo implicitly assigned the pointer to bar? In which case, why do you have to give the type of foo?

What the fuck? Please clarify

Because the compiler needs to know how big the data is at the pointer location.

Also pointer aliasing rule

In most cases you can't: stackoverflow.com/a/99010

Think of it like int *const. A pointer that can't be reassigned.

It's int* const, not const int*.

const int* is a mutable pointer to immutable data.
int* const is an immutable pointer to mutable data.

In either case, foo doesn't actually point to heap memory. In most contexts it's going to be stack memory.

wouldn't it be something more to the effect of
int foo[5] = { 16, 2, 77, 40, 12071};
int *something = &foo;

Yours is assigning foo to a pointer, when you need to assign the pointer to a reference to foo.

No, &foo is an int**

can people stop with this meme?
just because it degrades to the pointer to the first element, doesn't mean that's what it is

just think of them as 2d arrays

git gud

extern void *(*ops[][OP2MAX][OP3MAX])(void *);

holy shit guys

If we think of arrays as mailboxes which have a number to identify them then an array of pointers is just a mailbox that contains the numbers of other mailboxes containing other data.

>C is simp-

struct foo {
char data[10];
}

sizeof(foo) != sizeof(char*)

>actually using pointers

Attached: shiggy.png (398x410, 231K)

>Just abstracting away your problems so some other poor fuck can deal with it
only real programmer in this thread.

Attached: 1505634998449.gif (330x216, 966K)

>typed pointers in C are bad
>nullable references in every other language are fine

Stay pleb.

Horrible macro that doesn't work most of the time since arrays degrade into pointers when passed as arguments.

Wrong. They coerce to that type but they are a distinct type. You can write a function which takes an array but not a pointer.

>You can write a function which takes an array but not a pointer.

Post C90 prototype for such a function nao.

PROTIP: you can't

int main(int argc, char* argv[]);

nice bait

Exactly the same as

int main(int argc, char **argv);

Call it with a pointer to a single char * and it'll work. Seriously try it.

The array brackets in parameter list syntax is a carryover from the B language. Ritchie himself called it "a living fossil".

Nice one Ritchie

Attached: Untitled.png (362x93, 4K)

That's wrong.

Pointer to pointer and pointer to array are different types. However it is completely valid to write

int foo(int (*matrix)[3]);

and leave the innermost dimension unspecified.

kys nobody does that

In a parameter declaration, maybe not. In a definition with an initializer however, that's done all the time. Updating the dimensions when you add stuff to the initializer is a pain in the ass; it only makes sense to do it if the array is exported and the innermost dimension is #define'd in a header.

People who try to specify the inner dimension in a parameter declaration without C99 static syntax are dangerous fools. The compiler ignores it.

Arrays are not pointers.

This desu

They are both not fine.

Consistent position, but can you name a popular language that uses non nullable references by default and doesn't use sentinel objects to plug the holes?

I C++ references are immutable and can't be null. C++ pointers are mutable (by default) and are nullable. There are many sentinel objects to plug the holes though (smart pointers, std::optional as a nullable value type). I have no problem with that.

>this thread reminded me why I quit my well paying c/c++ job

Life's too short for c/cpp.

C++ uses nullable pointers (including smart pointer) all over; it's hardly a model of consistency. I also have no problem with that, but there's no denying it's inconsistent.

implementing non-nullable is not exactly hard though. I guess it's mostly not needed, since you can just make them const to have non-nullable reference semantics. If you really need non-nullable but rebindable smart pointers you can implement them (I don't see the value though).

I think the fact that nobody bothers indicates it's not a real problem.

The real problem with C is undefined behavior, not pointers in and of themselves. If unchecked array indexing, non trapping null pointer dereferences, and type punning required explicit annotations, nobody would complain about pointers. The last two aren't even all that expensive.

Not the guy you were responding to.
While I agree that undefined behavior can be dangerous and I'd prefer it just weren't there, it does allow for some tight compiler optimizations that wouldn't be otherwise: blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Learn what a stack is you literal nigger