Re: Zero-size array as struct member
Ian Collins <email@example.com> wrote:
On 08/22/10 04:44 PM, Juha Nieminen wrote:
Ian Collins<firstname.lastname@example.org> wrote:
You are cheating. std::set<int> != std::vector<int> and is in no way an
equivalent to a dynamically allocated array.
Try your test with a vector, before and after reserving space (which is
the more realistic comparison).
How many times does this have to be repeated?
What, that you cheated?
Cheated exactly how? I was demonstrating the speed of memory allocations.
Allocating a million std::set nodes and allocating a million instances of
(non-zero-sized) std::vector instances both cause a million memory
allocations. The point was to demonstrate the speed of memory allocation,
not the speed of std::vector vs. std::set. I could just as well have used
std::list, std::map or outright raw 'new' calls for the same purpose.
In other words, I was demonstrating the significance of the amount of
times that 'new' and 'delete' are executed.
Now you have a dynamically allocated instantiation of the struct, where
the size of the 'array' element is decided at runtime.
The struct hack is a C idiom which is seldom used in C++. In C++ we
have other techniques.
And this has what to do with my original point, namely that 'new' and
'delete' are heavy operations?
In the latter case there will be *two* allocations: One for the struct
and another for the std::vector. In the former case there will be only
So you *do* understand my point, finally? In other words, that with the
struct hack the total amount of memory allocations will be halved compared
to the cleaner solution (using a dynamically allocated array as the member
of the struct).
If you are making a huge amount of such allocations, it *will* be a big
deal because 'new' and 'delete' (or malloc() and free() if you like) are
quite heavy operations. That's what my example with the std::set was
std::vector::reserve has nothing to do with this.
neither has std::set.
The point was to demonstrate how heavy 'new' and 'delete' are.