Legitimate Use of Variable Length Arrays
nullprogram.com
Legitimate Use of Variable Length Arrays
1–10 of 26 posts
Re: Legitimate Use of Variable Length Arrays
#2> Stack allocations are trivial and fast by comparison: Allocation is a matter of bumping the stack pointer, and no synchronization is needed.
And this is why runtimes with moving garbage collectors can be faster than malloc - allocation with such a GC is always this cheap even when it's to the heap. (The costs move elsewhere, of course, but ideally to another thread, and are temporally and spatially grouped so that the work uses cache better.)
Re: Legitimate Use of Variable Length Arrays
#3"What’s the behavior in the VLA version when n is so large that sizeof(*identity) doesn’t fit in a size_t?"
Isn't size_t supposed to be as large as to fit the cardinality of the largest type you can create?
Re: Legitimate Use of Variable Length Arrays
#4> Stack allocations are trivial and fast by comparison: Allocation is a matter of bumping the stack pointer, and no synchronization is needed. And this is why runtimes with moving garbage collectors can be faster than malloc - allocation with such a GC is always this cheap even when it's to the heap. (The costs move elsewhere, of course, but ideally to another thread, and are temporally and spatially grouped so that…
Allocation is always cheap, also with manual memory management. It's reclaiming/freeing memory which is the tricky part ;)
Best approach is still to minimize dynamic allocation as much as possible. One can often get surprisingly far with an entirely static memory layout that's defined upfront at application start.
Re: Legitimate Use of Variable Length Arrays
#5"Legitimate Use of Variable Length Arrays"
There isn't any.*
The author shows what's at best a minor convenience, which is in no way worth all the downsides of which the author lists. For any actual use he'd have to wrap it in a function, if merely to have an assertion to check the array ranges. Oh, and have a version for compilers which don't support VLAs at all. At which point he might as well do the right thing always instead of VLA.
There author must be aware this isn't worth it. I guess the actual intent of the post was to show the author's knowledge, and indeed the author knows C and taught me some things I didn't know (VLAs are even worse than I thought them to be).
* Note that I'm talking about VLA, not stack allocation. There are better ways to do that when that's useful.
Re: Legitimate Use of Variable Length Arrays
#6"What’s the behavior in the VLA version when n is so large that sizeof(*identity) doesn’t fit in a size_t?" Isn't size_t supposed to be as large as to fit the cardinality of the largest type you can create?
In C++, at least, you are right.
> The type size_t is an implementation-defined unsigned integer type that is large enough to contain the size in bytes of any object.
§21.2.24(3)
Re: Legitimate Use of Variable Length Arrays
#7>If there’s any risk that nmemb is too large, it must be guarded. [...] However, if median is expected to safely accommodate COPY_MAX elements, it may as well always allocate an array of this size. If it can’t, then that’s not a safe maximum.
Et voilà, a library function that could have been portable between the smallest microcontroller and the largest workstation becomes restricted to a single application.
Re: Legitimate Use of Variable Length Arrays
#8"Legitimate Use of Variable Length Arrays" There isn't any.* The author shows what's at best a minor convenience, which is in no way worth all the downsides of which the author lists. For any actual use he'd have to wrap it in a function, if merely to have an assertion to check the array ranges. Oh, and have a version for compilers which don't support VLAs at all. At which point he might as well do the right thing al…
[deleted]
Re: Legitimate Use of Variable Length Arrays
#9> Stack allocations are trivial and fast by comparison: Allocation is a matter of bumping the stack pointer, and no synchronization is needed. And this is why runtimes with moving garbage collectors can be faster than malloc - allocation with such a GC is always this cheap even when it's to the heap. (The costs move elsewhere, of course, but ideally to another thread, and are temporally and spatially grouped so that…
Allocation is always cheap, also with manual memory management. It's reclaiming/freeing memory which is the tricky part ;) Best approach is still to minimize dynamic allocation as much as possible. One can often get surprisingly far with an entirely static memory layout that's defined upfront at application start.
In support of flohofwoe's point: good implementations of malloc will, on the common path, just bump a pointer without synchronization. The allocation path of good manual allocator implementations and garbage collectors will probably look similar.
Re: Legitimate Use of Variable Length Arrays
#10I ran into a great alloca bug back in the early days, think 2001 of OS X.
Used alloca to allocate a string on the stack. Depending on the size of the string the colours on the dialog would either look normal or have a rainbow like colour.
Turns out that alloca allocated the data on a non aligned memory address on occasion this caused the quartz compositor, which depended on aligned memory, to draw text with goofy colours.
Moral of the story, I don't use alloca anymore and if I do, I ensure that its aligned properly.