I think it cannot be done but why not?

[Simon]

Hi,

if I have an array, any array, why can I not get it's size?

for example

unsigned char *szTest = new unsigned char[10];

....

how can I get it's size?

I mean if memory for it is allocated then I should be able to get its size?

By size I mean the number of items in the array.

so in the example above

int nSize = sizeofarray(szTest); // = 10;

or even get the total allocated size

int nSize = arraysize(szTest)/sizeof(szTest[0])); // = 10;

regards.

Simon

 

[John Harrison]

Hi,

if I have an array, any array, why can I not get it's size?

for example

unsigned char *szTest = new unsigned char[10];

...

how can I get it's size?

I mean if memory for it is allocated then I should be able to get its size?

By size I mean the number of items in the array.

so in the example above

int nSize = sizeofarray(szTest); // = 10;

or even get the total allocated size

int nSize = arraysize(szTest)/sizeof(szTest[0])); // = 10;

regards.

Simon

The answer to all your problems is to use a vector instead. Vector is a
standard C++ class that operates very much like an array but has a whole
load of extra features. For instance your code above could be written like
this

#include <vector>

std::vector<unsigned char>szTest(10); // a vector of size 10
int nSize = szTest.size(); // the size!!!

john

 

[Simon]

The answer to all your problems is to use a vector instead. Vector is a
standard C++ class that operates very much like an array but has a whole
load of extra features. For instance your code above could be written like
this

#include <vector>

std::vector<unsigned char>szTest(10); // a vector of size 10
int nSize = szTest.size(); // the size!!!

john

I understands that there are ways around, I am just curious if/why the
standard does not have a function to tell me how much memory was
allocated for a certain item.

Simon

 

[Karl Heinz Buchegger]

[snip]
I understands that there are ways around, I am just curious if/why the
standard does not have a function to tell me how much memory was
allocated for a certain item.

Historical reasons: It was that way in C.

Why it was that way in C, I can only guess:
Memory considerations. The compiler would need
to store the number of elements somewhere and it seems
that K&R didn't want to do that. When you dynamically allocate
an array you already know its size, you have given it to
malloc (or new in the C++ case). Same for an auto-generated
array. The program already knows the size, so why store it with
the array?

 

[Tom Widmer]

Hi,

if I have an array, any array, why can I not get it's size?

The size of a dynamically allocated array might not be known at
runtime.

for example

unsigned char *szTest = new unsigned char[10];

...

how can I get it's size?

You can't portably. _msize is supported by some C runtimes, but may
not do what you want.

I mean if memory for it is allocated then I should be able to get its size?

Why? Some platforms might only record the number of elements in arrays
of objects with non-trivial destructors (so that it can destroy the
right number when you do delete[]). Also, the size of the block of
memory may be larger than the size of the array in any case. e.g. an
allocation of size 10 might be rounded up to 12 or 16.

Generally, you should use std::vector rather than a dynamic array.
std::vector can usually replace every use of bare dynamic arrays in a
typical program.

Tom

 

[angelo]

Simon wrote:

[snip]

I understands that there are ways around, I am just curious if/why the
standard does not have a function to tell me how much memory was
allocated for a certain item.

Historical reasons: It was that way in C.

Why it was that way in C, I can only guess:
Memory considerations. The compiler would need
to store the number of elements somewhere and it seems
that K&R didn't want to do that. When you dynamically allocate
an array you already know its size, you have given it to
malloc (or new in the C++ case). Same for an auto-generated
array. The program already knows the size, so why store it with
the array?

You have to understand that, though pointers and arrays are so similar
in many ways, they are not equal
when ever you define a pointer and with whatever value you assign it,
sizeof(the_pointer) will give the answer: the size of an pointer, which
in many of the platforms is 4 bytes.

 

[Alf P. Steinbach]

* Simon:

I understands that there are ways around, I am just curious if/why the
standard does not have a function to tell me how much memory was
allocated for a certain item.

Note that there are two items here:


A) How much memory was allocated (and should later be deallocated).

B) How large is the usable part of an array.


Regarding (A) that number _may_ be represented by the memory management. It
can be explicitly represented, e.g. as a field attached in front of the
memory area you get a pointer to. Or it can be implicitly represented. Or,
if the memory manager is one that sits on top of another one (e.g., calling
directly down to the OS), it might not even know the number (A). Requiring
a representation of (A) such that that number could be efficiently retrieved
could therefore impose some unacceptable overhead, depending on the details.

Another reason for not handing you the number (A) is that (B) might be very much
smaller than (A). For an array of class type objects, with constructors and
destructors, the rest of the memory area after the (B) first bytes is just unusable
garbage, so (B) is the only number that is safe to hand you.

The argument for not requiring the memory manager to store (B) is the same as for
(A), only more so.

For even though most of them -- if not all -- actually store (A) somewhere,
they have no reason of their own to store (B), so that would be pure overhead.
You would be paying for something very seldom used. And not having to pay for
something you don't use is a very important guiding principle in C++.

 

[Howard]

The size of a dynamically allocated array might not be known at
runtime.

I take it you mean at "compile time"? It's certainly known at runtime, as
it is allocated then, and the allocator had to know the number of elements.
(It's right there in the new statement!)

for example

unsigned char *szTest = new unsigned char[10];

[To the OP:]

And of course, since it IS right there in the new statement, there's no
reason it couldn't have been stored in a const int variable by the
programmer in the first place, and that variable later used when the size is
needed.

If you need to pass the array to a function, and need the function to know
the array size, then you need another parameter that states the number of
elements in the array. An easy way to handle that is to wrap the array in a
class which knows the array's size. And that's exactly what a vector
provides you (along with other niceties).

As for the memory used, that's oviously a whole other question, and depends
upon the memory used by each of the objects in the array, which may vary
among the objects in the array, and may change over time as those objects do
their own dynamic allocation of members.

-Howard

 

[Tom Widmer]

I take it you mean at "compile time"? It's certainly known at runtime, as
it is allocated then, and the allocator had to know the number of elements.
(It's right there in the new statement!)

No, I do mean runtime. Obviously the size is known at the moment of
allocation, but after that some allocators thrown it away. Some
allocators do store the size in an accessible way in some cases (e.g.
in the 4 bytes preceding the start of the allocated memory), but
others don't.

Tom