On 23 Nov 2019, at 5:05 am, Luboš Luňák <l.lunak@xxxxxxxxxxxxx> 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 > se. > >> - 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; >> by >> 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@xxxxxxxxxxxxx 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. Chris _______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice