Luboš Luňák wrote
...
To use std::fill, we'd need to convert the C array into std::array.
No, we wouldn't: std::fill( array, array + 10, value );
Indeed, I saw I was wrong when reading the Mike's response.
Luboš Luňák wrote
...
I think there wouldn't be any performance gain. Why should there be? Even
the
page you linked says that one of advantages of std::array is that it has
the
same performance as C array[*].
I wrongly made a shortcut, the potential is not about converting C array to
std::array but by using std::<algo> instead of the for each.
Since we can use std::<algo> on C array, the replace is useless.
Luboš Luňák wrote
...
Well, there are some that come to mind, such as "KISS" and "don't fix
what is
not broken" :). There actually are places where C arrays may be better,
such
as when the code is trivially simple, when interfacing with C libraries,
or
when using STL actually makes the code worse[**].
The goal is to replace some loops with std::<algo> . Of course, I don't want
to use std::<algo> if I need to add a complicated lambda.
About "don't fix what is not broken", I disagree here.
What about removing unused parts and optimizing? After all unused parts and
not optimized parts don't break anything that's not a reason for not
modifying them. Of course, sometimes there may have some regressions but
considering:
- perf bugtrackers
- time to build the whole code
- parts completely obsolete
...
It's not useless to have this maintaining task active.
Luboš Luňák wrote
But note that I'm not strictly opposed to this. I suppose there are
places
where std::array can do better. I just think that such changes should not
be
done blindly based on incorrect assumptions.
Indeed. I thought about submitting small targetted patches on gerrit.
Luboš Luňák wrote
[*] The performance will be about the same only in optimized code, which
the
article also forgets to mention.
Yes in debug mode with bound checkings, it'll be (a bit?) slower.
The paragraph "Performance and memory usage" mentions it.
Luboš Luňák wrote
[**] Which is not that hard given how clunky STL usage can be. I would
personally consider converting that transfer.cxx line to std::fill() to be
a
regression in readability. If STL, then it should be std::array::fill().
So if you consider replacing:
for (sal_Bool & rb : pToAccept)
rb = false;
by
std::fill_n(pToAccept, 128, false);
is a readability regression, no need I bother to submit patches for these
cppcheck reports.
Julien
--
Sent from: http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
Context
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.