About replacing some "C-Array" into std::array
chris.sherlock79 at gmail.com
Sat Nov 23 05:36:27 UTC 2019
On 23 Nov 2019, at 5:05 am, Luboš Luňák <l.lunak at collabora.com> wrote:
> On Friday 22 of November 2019, julien2412 wrote:
>> 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.
> That depends on definition of "broken". Unused or slow code may fit that.
> You asked for a guideline, not for a hard rule. I said I'm not against it per
>> - time to build the whole code
> Note that STL usage generally makes compilation slower, so this argument
> doesn't fit here as an argument for this topic.
>>> [**] 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;
>> std::fill_n(pToAccept, 128, false);
>> is a readability regression
> I didn't think of std::fill_n(). I wrote std::fill() and here "std::fill(
> pToAccept.begin(), pToAccept.end(), false )" is worse. But even the
> std::fill_n() case is debatable because of the need to specify size. Which is
> why I said that std::array with its fill() would actually fit better here.
> Luboš Luňák
> l.lunak at collabora.com
I thought that std::fill was used to try to avoid bounds errors. In particular, the example given in the CppCoreGuidelines is to replace memset.
More information about the LibreOffice