http://d.puremagic.com/issues/show_bug.cgi?id=5348
--- Comment #1 from bearophile_h...@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: -------
