* 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++.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?