Thread: Arrays and pointers to allocated memory

Originally Posted by TriKri

If you declare

int x[500][1000];

does x[i] give you the pointer to the first element in the i:th-array? Or is x[i] the whole i:th array itself?

Test it yourself. Print the address of x[0]. Now print the address of x[1]. Do a bit of math, get your answer.

Originally Posted by TriKri

Is there any way to se how large the allocated memory is?

No.


Quzah.

I see another recommendation to visit this page:
http://www.torek.net/torek/c/pa.html

because

does x[i] give you the pointer to the first element in the i:th-array? Or is x[i] the whole i:th array itself?

the first element is an array.

Originally Posted by TriKri

Is there any way to se how large the allocated memory is? I mean, when you use free(string), it must be known somewere how big the allocated area is, right? And then you could be able to check how large area you allocated?

Just remember how much you ask for.

Originally Posted by Mortissus

The "whole array" is acctually a pointer to a block of memory.

No it isn't. Not any more than a "whole int" is "acctually a pointer to a block of memory". Array names, though similar in most ways, are not pointers.


Quzah.

Code:

int myarray[];

is not a valid declaration.

Originally Posted by TriKri

But what about writing

Code:

int myarray[];
myarray = malloc(100 * sizeof(int));

Does myarray really become an array or does myarray become a pointer? Now I am lost.

myarray starts as a pointer, and it ends as a pointer to some memory. The memory can be addressed as an array just like other pointers.

> is not a valid declaration.
It was, deep in the mists of time.
http://www.cs.bell-labs.com/who/dmr/primevalC.html

Is there any way to se how large the allocated memory is? I mean, when you use free(string), it must be known somewere how big the allocated area is, right? And then you could be able to check how large area you allocated?

Good point. When malloc() (or new in C++) allocates memory it writes a header for it that keeps some metadata like the size of it. There should be a way of reading this header for example with a function lile getmeminf(), why not?

And about arrays and pointers: http://www.cplusplus.com/doc/general/Arrptr.html

> There should be a way of reading this header for example with a function lile getmeminf(), why not?
There might be, but there is no PORTABLE way to find out, short of writing your own wrapper around malloc and free to keep track of the size.

So have a look through your compiler specific documentation, and decide for yourself whether the loss of portability is worth it.

If such thing exists it should be found in <new> header, but I didn't find any function to do such thing.

If such a thing exists (which it doesn't) in <new> (which it doesn't), it would be C++, not C.

For C it should be found in stdlib.h among other related functions that are:

Code:

void *  calloc(__in size_t _NumOfElements, __in size_t _SizeOfElements);
void   free(__inout_opt void * _Memory);
void * malloc(__in size_t _Size);
void * realloc(__in_opt void * _Memory, __in size_t _NewSize);

It is strange to me that there is no such function. It should be standard in C/C++ and should take the pointer as argument and return its size at least. I don't know what information can be found in the header of allocated memory.

Well since my code usually looks like

Code:

size_t howmany = 123;
int *myArr = malloc ( sizeof *myArr * howmany );

Why would I need a library function to tell me how many bytes have been allocated when I already have a variable telling me how many bytes have been allocated?

And if you do pass that to another function with say
foo ( myArr );
Why is it so hard not to change it to
foo ( myArr, howmany );