Re: What is the output of this program?
* James Kanze:
Alf P. Steinbach wrote:
* James Kanze:
Alf P. Steinbach wrote:
* kanze:
Earl Purple wrote:
Alf P. Steinbach wrote:
push_back can be a tad inefficient on strings, because
strings are usually short, and for short sequences the
reallocations, assuming scaling of buffer size, are more
frequent and thus more costly.
I don't think it's the allocations that make push_back
inefficient, (you can do reserve() ahead and std::string
will often allocate enough anyway). What makes it
inefficient is that push_back has to do a bounds-check on
every call (how else will it know whether to reallocate?).
Much more efficient is resize().
I doubt it. I also doubt that either make a significant
difference.
Possibly you're talking about something entirely different
than the following program?
[snip]
point where even if one version were ten times faster than the
other, I can't see it making significant difference in an actual
program.
Oh, come on. One order of magnitude is significant.
One order of magnitude in the execution time of the complete
application is significant. Whether it takes me a milliseconde
or 10 millisecondes to format a message that I output only a
couple of times a minute (or less) is not significant. And in
an awful lot of programs, the only thing you're doing with
std::string is formatting output messages (which aren't that
frequent) or parsing the configuration file (once on start up).
So the earlier assertion, "I also doubt that either make a significant
difference", was not meant to state that there was no significant
difference, but really that in some context of your choosing, there
would be no significant difference on some measurement of your choosing.
That's meaningless.
One such context is to put the code in a function that's never called,
ever, where the measurement is anything else than lines of code.
I maintain, as I wrote, that "push_back can be a tad inefficient on
strings".
And I submit my earlier little demonstration program as easily
reproducible evidence.
Also, when you can do something efficiently at about the same cost in
programmer time as inefficiently, it's not reasonable to choose the
inefficient way, then measure performance and so on to determine whether
it has to be changed to the efficient way you could have used in the
first place.
If you just avoid the hugely inefficient operations, and also refrain
from quadratic time algorithms and the like (and worse), then likely the
application will be fast enough and consume so little memory that the
performance analysis & associated detective work, changes & retesting
becomes unnecessary.
--
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?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]