On Wednesday, February 22, 2012 14:12:07 Jonathan M Davis wrote: > 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.
Also, wouldn't it be less efficient if you _had_ to copy the array once you were done with the appender? That would seem to go against what appender is trying to do. - Jonathan M Davis