On Friday, 8 March 2013 at 22:59:23 UTC, Namespace wrote:
Wow, very large. I'm going to read this tomorrow in a rested
state in more detail. But it arouses my interest to write
something yourself from scratch.
But a quick question: Why is the internal array in the separate
struct 'Data' encapsulated? To enable a performant postblit,
since only a pointer need to be copied? If so, I thought the
nested struct must be static?
AFAIK, it is to have refernce semantics on copy: EG: To pass an
appender by value, but still have observable modifications. Its
basically the "hand written class implementationvia structs"
semantic.
Note though that it does have the fatal flaw that if the Appender
is not initialized (allocated payload), then you won't actually
see the modifications if you immediatly pass it by value (eg: use
appender as a sink for format, for example). But this is more of
a "D-wide" issue. I recommend always initializing your appender
to (at least) a null array: It is not useful in and out of
itself, but forces payload initialization.
----
Declaring the struct as static enforces that it doesn't have a
context pointer. However, if it is not declared as static, and
doesn't need a context pointer, it won't have one. the keyword
static is an "opt-in" keyword. It is also very under-used in
phobos, but I think it is good practice to use it as much as
possible.
----
I've tried to write an array re-implementation, but it is
delicate work. Up until now, I've been fixing or improving more
minor things. That and the fact that very few of my pulls seem to
actually go through and just pile up, I'm trying to not burdern
the reviewers with a complicated development.
Maybe I should be more pro-active and getting my stuff reviewed?
