hi, i disagree. i really like variable length arrays. and std::vectors dynamically allocate memory on the heap, with standard implementations locking a global mutex on the way, causing slowdown for multithreaded cases. just incrementing the stack pointer is a simple thing, it's thread local and light weight. and memory resources will run out whether i do a complicated or a simple memory allocation scheme (with linux overcommitting, you can't even test malloc == 0, so i don't see how heap allocation is any safer). also, variable sized arrays mean it's not known compile time, but once you enter the function you know exactly how large you need it (no need for dynamically growing complicated structures).
i understand however that some libc implementations have issues with that and that it makes people feel uncomfortable about predicting whether the code is correct or not. so we do the inconvenient grown-up thing and warn about it in dt. cheers, jo On Sat, Sep 23, 2017 at 8:07 AM, Heiko Bauke <heiko.ba...@mail.de> wrote: > Hi, > > Am 22.09.2017 um 15:35 schrieb Tobias Ellinghaus: >> >> No, you are missing the point of those pragmas: darktable from git always >> builds with "-Werror", thus the "-Wvla" switch actually throws an hard >> error >> when using VLAs. With the pragma we are relaxing that back to a warning >> again >> to be able to use VLAs in some places. > > > I understand, makes sense. After reading the article about the save usage > of variable length arrays mentioned in my other mail, I thing variable > length arrays are actually not as great as I thought. What one really wants > is probably a std::vector. But this has not yet been invented in C. > > > > Heiko > > -- > -- Number Crunch Blog @ https://www.numbercrunch.de > -- Cluster Computing @ http://www.clustercomputing.de > -- Professional @ https://www.mpi-hd.mpg.de/personalhomes/bauke > -- Social Networking @ https://www.researchgate.net/profile/Heiko_Bauke > ___________________________________________________________________________ > darktable developer mailing list > to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org > ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
