In the stackoverflow question "What does enabling STL iterator
debugging really do?" [1], the top answer points out that creation and
destruction of STL iterators in debug mode is comparatively expensive.
The example given in the answer is:
for (iterator_t it = vec.begin();
it != vec.end(); // Oups
++it)
// body
LibreOffice has quite a number of loops written this way. Do we care?
My builds with --enable-dbgutil are noticeably slow, but (a) that
build option does other things, too; (b) my machine is very
underpowered for this task; and (c) most people do not use debug
builds. So, possibly we do not care. OTOH, hoisting vec.end() so
that is is called only once should be a quite mechanical task, even a
candidate for an easyhack.
FWIW, the output from
git grep --extended-regexp '((for)|(while)) *\(.*\. *end\('
was 2974 lines when I looked at it. An examination of 13 lines from
the output shows that 10 of them evaluate end() in each iteration.
Measurement of the actual cost in performance is beyond my capability.
Just for reference, note the thread on the this list "General question
about vectors" [2], which discusses the choice between `for` loops and
`for_each` calls.
Thoughts?
Terry.
References:
[1] <http://stackoverflow.com/questions/2731419/what-does-enabling-stl-iterator-debugging-really-do>
[2] <http://nabble.documentfoundation.org/General-question-about-vectors-td4094114.html>
Context
- STL iterators and for loops · Terrence Enger
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.