On Wednesday, February 22, 2012 12:16:43 Robert Jacques wrote:
> There's a big difference between sealed and not accessible. .data's
API
> requires exposing an array, and there's no way to do this without
leaking
> memory like a sieve in one way or another. However, if all you need
is to
> iterate the contents, that's easy to do. I'm currently adding
backwards
> iteration. Even indexing is fairly efficient (not yet implemented),
> particularly relative indexing (i.e. n from back or front).
>
> I haven't seen too many use cases yet where accessing the underlying
array
> is important, nor has it come up on bugzilla. I've found one case in
> Phobos where appender was used as a stack. What's your example? What
> features does it have to support and how efficient does it have to be?
It's can be useful to just get at the underlying array and pass it to
functions which are going to use it but not alter it (or at least not
append
to it). Iterating over it doesn't give you an array. And since
appender's
entire purpose is simply to make appending to an array more efficient,
making it impossible to treat it as one until you're done appending is
overly restrictive IMHO. Yes, if you leak references to the underlying
data, you're asking for trouble, but that doesn't mean that it can't be
used without leaking memory.
Unfortunately, I don't have any code snippets with me at the moment, so
I
can't give any concrete examples of usage, but any situation where you
want
to be able to operate on the array while building it needs the ability
to
get at the underlying array. Yes, in most cases, you're probably simply
appending to the array, but at least once in a while, you need to
operate
on an array while building it.
