The Thermopylae excerpt of TDPL available online

[Andrei Alexandrescu]

Michael Rynn wrote:
> On Thu, 29 Oct 2009 12:23:18 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
> 
>> 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!
> 
> 
> Good chapter, I learned some things, and I liked the Unicode
> exposition.
> 
> Pg 114.  5   
> 
> Did not understand why this code is a compiler bug.   To me its a
> 'feature', consistant with behaviour of underlying realloc, capacity
> and length management, and consistant with having average good
> efficiency for a ~= item. I do not want a clever compiler trying to
> predict existance of an array aliasing.
> 
> Its a nice example of aliasing, only it seems just a bit harsh on the
> poor old compiler.  Not good to have every page virtually subtitled ,
> nice language, shame about the compiler..
> 
> I would like to see a function in std.array for D2, that does
> efficiently what the example asserts should be possible, to force a
> new allocation when required, in a simple one line statement,
> syntactically sugared.
> 
> // At this point a and b are adjacent
> //a ~= [0, 0, 0, 0];
> /// Concantenation function which will gaurantee to return array using
> only single new memory allocation containing a ~ b, for when you
> really need it.
> // T[] concat(T[] a, T[] b)  // maybe  more varargs
> 
> a = a.concat([0, 0, 0, 0]);   
> 
> // OR in 2 lines just make the intention clear
> 
> auto c = a ~ b; // this should work just the same?
> a = c;
> 
> assert(b == [40, 50, 60, 70]); // passes; a got reallocated
> 
> P114. 40
> 
> array.length op=   something.
> // compiler  message that array.length is not an lvalue.
> 
> I like the compiler message.    Admittedly I would like the shorthand
> too, but I do not see it as bug, because it reflects the C heritage.
> Another feature.   Would like at least these bugs to be features..
> 
> P 123.  30
> You didn't mention the in operator for AA returns a pointer to the
> keys value, or null  This got me a little worried, as I liked using
> the value returned by in operator, and had not used .get at all.
> 
> 
> 
> P 128 20-25
> 
> .."To support this encoding, Unicode
> allocates no valid characters to numbers in the range 0xD800 through
> 0xDBFF"
> 
> Typo  ,   should be:   0xD800 through 0xDFFF here.
> 

Thanks, I added this to my worklist.

Andrei