[Issue 5348] Variable Length Arrays

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=5348



--- Comment #1 from bearophile_hugs at eml.cc 2011-01-03 04:22:18 PST ---
Some comments by Dmitry Olshansky:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=125942

> As stated in this proposal they are quite useless, e.g. they are easily 
> implemented via mixin with alloca.
> Plus, what's the benefit in throwing exception on alloca failure, how 
> you suppose the user to handle this stackoverflow exception? I would 
> have expected a better design to provide an optional parameter to 
> fallback to GC or something ( like malloc(...) + scope(exit) free(...); 
> ) and that's indicates a library solution, of course.



Some answers to Dmitry Olshansky:

> As stated in this proposal they are quite useless, e.g. they are easily 
> implemented via mixin with alloca.

This is false, a mixin solution can't replace a VLA because:
- The compiler knows what a VLA is, so it may copy it automatically (as it does
with fixed-sized arrays) if you return a VLA from a function.
- vla_array.sizeof gives the correct answer
- alloca() is not pure, while a function that uses VLA can be pure.
- The VLA syntax is nicer, it doesn't look like hack, this encourages their
usage, and it doesn't require imports. And if you need a 2D variable length
matrix, you don't need a different mixin, the VLA syntax supports multi
dimensional arrays.


> Plus, what's the benefit in throwing exception on alloca failure, how 
> you suppose the user to handle this stackoverflow exception?

The proposal says that an error too is OK:
> When a VLA array is allocated the D compiler tests that there is enough free stack left, and otherwise throws a runtime exception/error (like stack overflow).


> I would 
> have expected a better design to provide an optional parameter to 
> fallback to GC or something ( like malloc(...) + scope(exit) free(...); 
> ) and that's indicates a library solution, of course.

This is a possibility to keep in mind. But it makes the VLA implementation a
bit more complex:
- in the current proposal the VLA is represented by just a length. If you add a
fall-back mechanism then you need to keep a pointer too on the stack.
- If you return a VLA the code has to copy the data contents only if the VLA is
allocated on the stack. 
- This semantics is different from the C99 one. So people that know C99 need to
read about this difference and understand it, and C99 code ported to D probably
needs to keep in account the difference.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------