one thing I never understood about VLAs - discussion about them always hits a "can't put it on stack safely" and gets halted, forever

why not to make it heap-only type? it seems such a useful addition to type system, why ignore it due to one usecase?

▲

Out_of_Characte 3 days ago | parent | next [-]

Because arrays simply do not deal with fragmentation. Yes, you could probaly get decent performance on a modern system that has memory overcommit strategy where you could allocate sparse adress ranges where you would probaly never run out of pointers unless you actually write to your variable array.

But its just kind of mediocre and you're better off actually dealing with the stack if you can actually deal with certain fixed sizes.

▲

konstantinua00 3 days ago | parent [-]

...what are you talking about?

array-like storage with dynamic size has existed since forever - it's vector. over or undercommitting is a solved problem

VLA is the way to bring that into type system, so that it can be it's own variable or struct member, with compiler auto-magic-ing size reading to access members after it

	▲	Out_of_Characte 3 days ago \| parent [-]
		> auto-magic-ing size reading to access members after it From the article >we now have everything we need to calculate the size, offset and alignment of every field, regardless of their positioning in the struct. >init to allocate the memory >get to get a pointer to a field >resize to resize the arrays >deinit to free the memory You're now suggesting to do exactly what the article is about without being aware of it.

▲

ori_b 3 days ago | parent | prev | next [-]

Those effectively exist. They're called slices.

▲

uecker 3 days ago | parent | prev [-]

You can also put them safely on the stack. The VLA is discussion is just irrational.