Re: Zero-size array as struct member
On Aug 21, 8:50 am, Juha Nieminen <nos...@thanks.invalid> wrote:
Why? IMO, new and delete are, on the success path, practically
equivalent on many common implementations. Difference is one if on
malloc failure, and new is inlined.
You are basing your claims on your personal *opinion*? Rather than,
you know, actually testing it in practice?
I say this claim of yours is poorly founded.
It's quite well founded. For example, take this short piece of code:
int main()
{
std::set<int> someSet;
for(int i = 0; i < 10000000; ++i) someSet.insert(i);
}
Oh, come on! set is not a vector. That's a MAJOR flaw in your example
and example is therefore completely of the mark.
'new' and 'delete' are significantly heavy operations.
Additionally, using std::vector there will increase memory fragmen=
tation,
making things even worse.
In this case, you can use vector::reserve, so not really.
If you are allocating a million instances of the struct, each such
instance having an std::vector object inside, reserve() would do nothing
to alleviate the memory fragmentation.
What!? Reserve would cause exactly 0 memory fragmentation, at least
until code starts reallocating or freeing these vectors, at which
point, there would be, fragmentation-wise, little, if any, difference
between a vector and discussed struct hack.
And even locality of reference is not a concern, because allocators
mostly do a good job of allocating blocks close in space if allocation
is close in time. E.g.
std::vector* p = new vector;
p->reserve(X);
is in practice quite OK wrt locality.
Not if the memory is heavily fragmented, which is one major problem h=
ere.
You're still to prove how memory is fragmented. Until you reach
reserved size in a vector, there's no fragmentation.
All you have is one allocation more with a vector. That's easily
swamped by the rest of the code, especially if you have millions of
elements in it.
You need to have _a lot_ of vectors, all with a _small_ number of
elements in it for your complaint to be relevant. And for that,
there's no need to use contortions until one can measurein running
code, that performance hit is indeed relevant. You are trying to do it
backwards, and especially because programmers are proven time and time
over to be poor judges of performance problems.
Goran.