Making generalized Trie type in D
Roman D. Boiko
rb at d-coding.com
Tue Jun 5 06:27:10 PDT 2012
On Tuesday, 5 June 2012 at 12:57:10 UTC, Dmitry Olshansky wrote:
> On 05.06.2012 9:33, Roman D. Boiko wrote:
>> On Tuesday, 5 June 2012 at 05:28:48 UTC, Roman D. Boiko wrote:
>>> ... without deep analysis I can't come up with a good API /
>>> design for
>>> that (without overcomplicating it). Probably keeping mutable
>>> and
>>> immutable APIs separate is the best choice. Will return to
>>> this
>>> problem once I get a bit of free time.
>> Simplest and possibly the best approach is to provide an
>> immutable
>> wrapper over mutable implementation, but that may be difficult
>> to make
>> efficient given the need to support insert / delete as common
>> operations.
>>
>
> I suspect I would have to add another policy like Persistent
> that will preallocate some slack space implicitly so that some
> pages can be shallowly copied on each assign(a-la COW) and
> immutable parts still reused.
> Another simpler way would be to use an separate field
> "pointer-to-actual base" for each level, thus allowing it to
> redirect it away to new (modified) copy. Still looks like
> policy as it _maybe_ slightly slower.
>
> Anyway as a start this should work:
>
> auto modifyDupGlobalImmutableTrie(Trie(immutable(T), ...) t
> , scope delegate(Trie(immutable(T), ...) )pure dg) __pure__
> {
> auto copy = t.dup;//this would be one day a shallow copy
> with(copy)
> {
> dg(copy);
> }
> return copy;
> }
>
> //later on
> {
> ...
> immutable newTrie = modifyDupGlobalImmutableTrie(yourTrie);
> ...
> }
Yes,something like that should work. I finished support request
and will investigate this and your std.uni. maybe it is better to
avoid immutability... or do bulk ins /del before copy.
More information about the Digitalmars-d
mailing list