Andrei Alexandrescu wrote > Saaa wrote: >> Andrei Alexandrescu wrote: >>> Andrei Alexandrescu wrote: >>>> Saaa wrote: >>>>> Could anybody clear these up for me? >>>>> >>>>>> p16. Is there anything other than the random values, unsafe about >>>>>> void assignment? >>>> I'd put your feedback on my pile of things to do, but now that you ask, >>>> I made this change to the incriminated paragraph: >>>> >>>> =========== >>>> Such uninitialized arrays are particularly useful for large arrays >>>> that serve as temporary buffers. An uninitialized integral may not >>>> cause too much harm, but uninitialized values of types with >>>> indirections (such as arrays themselves) are unsafe. >>>> =========== >>>> >>>>>> p18. What is unsafe about implicit conversion of static to dynamic >>>>>> array? >>>>>> Meaning getting a dynamic array pointing to a stack allocated >>>>>> array. >>>>>> Any operation changing its size could copy the array to the >>>>>> heap. What am I missing >>>> T[] fun() { T[10] a; return a; } >>>> ... >>>> auto x = fun(); // gained access to recycled stack memory >>>> >>>> There's no change in size there. >>>> >>>>>> p20. 10 int take up 40 words? >>>> The example given has a per-row payload of 10 ints, i.e. 40 words. >>> It's bytes actually. So finally I rewrote those last words as: >>> >>> "... small per-row payload of~10 @i...@s (40 bytes)." >>> >>> >>> Andrei >> >> Thanks ! >> >> Out of interest, do you keep a list of common error or something alike >> that helps you keep errors at a minimum? > > I got as sophisticated as having an email folder dedicated to TDPL. > >> Also, do you have automated example checking? > > Yes. If you look at the document very closely, you'll see that some > snippets have a thin line above and below them. Those are automatically > checked every time I save the document. (There are 1-2 examples that > aren't checked in the Thermopylae excerpt because I switched editing to a > 64-bit machine that can't build D programs (I'll post a question later > today). But in the meantime I fixed those.) > > Very short snippets do not have a thin line above and below them. Those > are not checked because they are short enough to warrant that I know what > I'm doing. :) > > Some checked snippets wouldn't compile without being in a function, for > example: > > enum size_t columns = 128; > // Allocate a matrix with 64 rows and 128 columns > auto matrix = new double[columns][64]; > // No need to allocate each row - they already exist in-situ > foreach (ref row; matrix) { > ... // use row of type double[columns] > } > > These are automatically entered inside a unittest. Also, my code > extraction script (written in D!) automatically eliminates unneeded I Wouldn't accept it being written in C++ !! :D
> "...", so the code as seen by the compiler is: > > unittest { > enum size_t columns = 128; > // Allocate a matrix with 64 rows and 128 columns > auto matrix = new double[columns][64]; > // No need to allocate each row - they already exist in-situ > foreach (ref row; matrix) { > // use row of type double[columns] > } > } > > which passes compilation. > > Some other examples need "invisible" support: > > writeln("hey"); > > For those I have a special mechanism to insert invisible code, so my text > for the above actually looks like this: > > \begin{D-invisible} > import std.stdio; > \end{D-invisible} > \begin{D-snippet} > writeln("hey"); > \end{D-snippet} > > What the compiler sees is a file importing std.stdio and including the > writeln inside a unittest. nice > > I wouldn't know how to pull this off reasonably with e.g. Word, but I'm > sure it now has mechanisms or extensions that allow that kind of thing. > One thing I don't need to worry about with LaTeX is that it's text-based > so I can process it easily myself. Somehow I only associate LaTeX with b/w scientific articles :) > >> Or, more general, I would be interested in a small article explaining how >> a book like this is written. >> >> Maybe After the book is finished :) > > I think the topic is well worth an article indeed. I continuously > streamline the process of building the book, and it's gotten pretty > sophisticated but very helpful as well. Index building is also an > interesting subtopic. > > > Andrei Thanks, looking forward to the article ( and the tools used :P )