new std.variant (was Re: The Right Approach to Exceptions)

[Robert Jacques]

On Wed, 22 Feb 2012 14:17:09 -0600, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:
> 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

No, because the array doesn't actually exist until appender makes copy.  
Internally, appender is using a list of arrays to store the data (similar  
to a VList and string builders from other languages). So it's little o(2N)  
for both memory and speed; the current appender is much worse than that.  
In terms of actual performance, on a clean machine I'm substantially  
faster for N < 4k (thanks to a free list), about the same for things of a  
few k in size, and then as things get bigger the current appender tanks.