Leandro Lucarella wrote:
Leandro Lucarella, el 29 de octubre a las 13:21 me escribiste:
Andrei Alexandrescu, el 28 de octubre a las 23:38 me escribiste:
It's a rough rough draft, but one for the full chapter on arrays,
associative arrays, and strings.
http://erdani.com/d/thermopylae.pdf
Any feedback is welcome. Thanks!
It looks very nice. A small error in 4.1.7 first code block:
auto a = new double[4]; // must be already allocated
auto a1 = [ 0.5, -0.5, 1.5, 2 ];
auto a2 = [ 3.5, 5.5, 4.5, -1 ];
a[] = (a1[] + a2[]) / 2; // take the average of b and c
^^^^^^^^^^^^^^^^^^^^^^^^^^^
take the average of a1 and a2?
(I think it would be easier to follow using b and c though ;)
BTW, it looks like array literals will be dynamic arrays, from the code in
your book. Can you or Walter explain why this is better to make array
literals statically stored immutable memory like strings (which adds an
inconsistency to the language)? Is this just to avoid [1,2,3].dup; when
you want to get a dynamic array from an array literal or is there other
reasons?
I don't have a better explanation than the excerpt:
Beware, however: if you replace @int[3]@ above with @auto@, @a@'s type
will be deduced as @int[]@, not @int...@. Although it seems logical
that the type of \cc{[1, 2, 3]} should be @int[3]@ which in a way is
more ``precise'' than @int[]@, it turns out that dynamically-sized
arrays are used much more often than fixed-size arrays, so insisting
on fixed-size array literals would have been a usability impediment
and a source of unpleasant surprises. Effectively, the use of
literals would have prevented the gainful use of @a...@. As it is,
array literals are @T[]@ by default, and @T[n]@ if you \emph{ask} for
that specific type and if @n@ matches the number of values in the
literal (as the code above shows).
Andrei
