Re: About replacing some "C-Array" into std::array

[julien2412 <serval2412@xxxxxxxx>]

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
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice