Leandro Lucarella wrote:
Andrei Alexandrescu, el 29 de octubre a las 12:23 me escribiste:
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:
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).
I saw that, but I think introducing an inconsistency (and depart on how
literals usually work) is worse than having to explicitly state the type
or adding a .dup to the literal.
But I guess it's just me.
It's me as well. The decision didn't go without a fight (I had your
viewpoint and Walter didn't). He convinced me with two arguments. One is
that 90% of the time you actually want T[], not T[n]. The second is that
string literals already have dynamic (not static) type, although the
most informative type would be fixed-size.
Another question about the book: you explain dynamic arrays are being
represented by a start and end pointer, much like the STL, but that's not
the real implementation. I know you say in the book that the
implementation doesn't necessarily work like that, but I wonder if you
decided to explain things like that because it's planned to change the
dynamic arrays implementation or just because you found it more didactic.
We will change the implementation at some point, but right now I hope I
made it clear enough it's about the notion of a bounded chunk of typed
memory, than the representation of it.
Andrei
