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


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@collabora.com

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.