About replacing some "C-Array" into std::array
julien2412
serval2412 at yahoo.fr
Fri Nov 22 17:26:34 UTC 2019
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
More information about the LibreOffice
mailing list