Date: prev next · Thread: first prev next last
2019 Archives by date, by thread · List index


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.