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