Re: about new and delete
* Sam:
Alf P. Steinbach writes:
* Sam:
Alf P. Steinbach writes:
No.
Can you figure out what's wrong with your measurement?
Yes: nothing.
Well, OK, that may explain your apparent bafflement at the comments
you're drawing.
Yes. No amount of grandiose pondering on various theoretical aspects of
various algorithms has any impact on the practical conclusion that, for
OP's case, std::list is the best solution.
OK, I put it in first-year-student terms but that wasn't enough.
I'm sorry but I don't think it can be simplified more than that. At least not by me.
The key to understanding this is to combine three pieces of information:
* The C++03 standard requires a contiguous buffer for std::vector.
* push_back has guaranteed amortized O(1) complexity.
While std::list::push_back()'s complexity is guaranteed constant, with
no additional qualifiers. Period.
* Allocation is generally way more costly (time) than copying a
handful
of bytes.
Regarding the last point it seems that you have a fast allocator. This
influences the relative performance of std::list versus std::vector.
Indeed. I'm only using the most popular compiler, and the most popular C
library, on non-MSFT platforms. Gee, I really worked so hard to assemble
such a marginal environment in order to gather those metrics.
In short, the main problem with your test was that you tested only a
single n which was not just small but very small (namely 10). Instead
your test should
Yeah -- just like OP's test program, where I suggested that he'd look at
std::list, instead. I must've missed the part where he was trying to
allocate memory for a million ints, and meticulously typing all of them
in from the keyboard.
Try with more than ten elements.
Talking about millions is, sorry to be blunt, idiocy.
And your analysis, which was aimed to defend one's bias towards
std::vector, conveniently neglected to consider all the other factors
that work to the detriment of std::vector:
1) Objects with expensive copy constructors
2) Objects of large size
Both will work to make std::vector's overall performance worse than
std::list's, as the number of elements in the container increases.
Sorry, that's incorrect.
Your argument for std::vector was resting on theoretical aspects of
std::vector and std::list's complexity outside of the boundaries of the
original OP's use case,
Sorry, that's incorrect.
and had no practical elements. However, once you
went beyond the original OP's requirements, and confined to theoretical
factors only, your argument was artificially limited to only those
theoretical factors that work in std::vector's favor, and they seemingly
ommited all the factors that work in std::list's favor.
I'm sorry, but an analysis of complexity isn't a set of arguments for and
against. It isn't an emotional thing feeling your way to a decision about which
arguments are strongest or most convincing. It's simple *math*, in this case at
the secondary school level, and you can check that math by simple programs.
However, since you failed to understand it, and since I don't know how to
simplify it even more, I think that's that.
Cheers & hth.,
- ALf