The Thermopylae excerpt of TDPL available online

[Leandro Lucarella]

Andrei Alexandrescu, el 29 de octubre a las 13:30 me escribiste:
> 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[3]@.  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 @auto at .   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).

Oh, ok. Thanks for the fight ;)

> He convinced me with two arguments.  One is that 90% of the time you
> actually want T[], not T[n].

I don't know how did he come up with that number. At least, talking about
arrays that comes from a literal, I don't think that is the case. In
a program I'm sure more than 90% of the array usage are dynamic arrays,
but when talking about array literals I'm not very convinced, I think you
usually just want an iterable from them.

> The second is that string literals already have dynamic (not static)
> type, although the most informative type would be fixed-size.

Damn! Are you saying that this:
auto s = "hello";

Really does something like this in C:
char* s = gc_malloc(5, NO_SCAN);
memcpy(s, "hello", 5);
?

I though it was just like C, a pointer to an statcally allocated memory
block. What's the point to heap-allocate an immutable chunk of memory?

> >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.

I think the point is taken, I was just curious about what's the plan.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Salvajes, de traje, me quieren enseñar
Salvajes, de traje, me quieren educar