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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread 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@xxxxxxxxxxxxx
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux