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