new std.variant (was Re: The Right Approach to Exceptions)
sandford at jhu.edu
Wed Feb 22 10:16:43 PST 2012
On Wed, 22 Feb 2012 11:33:57 -0600, Jonathan M Davis <jmdavisProg at gmx.com>
> On Wednesday, February 22, 2012 08:19:38 Robert Jacques wrote:
>> To Variant? Yes, definitely. To Appender? I don't think so. There is an
>> slight change in API behavior necessitated by performance
>> but I don't think it warrants a review by the community at large.
>> Specifically, appender's internal data structure is now sealed, which
>> that .data must always make a copy. My preference would be to deprecate
>> .data in favor of a .dup/.idup pair. It'll break a bunch of code (which
>> don't like), but it will make sure no one is calling .data twice in a
>> resulting in a silent performance problem.
> I've definitely written code that needed to get at data while appending.
> would consider it to be a huge downside to not be able to efficiently
> get at the
> current state of the array within the appender. Why on earth would you
> - Jonathan M Davis
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?
More information about the Digitalmars-d