On Monday, 23 February 2015 at 21:33:35 UTC, Steven Schveighoffer
wrote:
It means that it can do that, and does do that in dcollections.
std.container does not have all the code to do it,
dcollections.RBTree has some extra calls that would probably
help. However, the allocation is done in one s
On 2/23/15 3:16 PM, "Nordlöw" wrote:
On Monday, 23 February 2015 at 19:24:32 UTC, Steven Schveighoffer wrote:
In answer to your question, RBNode should not be accessible direction
outside of RedBlackTree. But we don't have allocators inside of
Phobos, so I used the easiest thing I could for port
On Monday, 23 February 2015 at 19:24:32 UTC, Steven Schveighoffer
wrote:
In answer to your question, RBNode should not be accessible
direction outside of RedBlackTree. But we don't have allocators
inside of Phobos, so I used the easiest thing I could for
portability.
-Steve
Does this mean t
On 2/20/15 4:26 PM, "Nordlöw" wrote:
What's the policy on using GC or not in std.container.* ?
- std.container.Array uses malloc for its allocation but
- RedBlackTree.allocate() returns a: new RBNode!Elem*
Is this because RBNode* should be reachable outside of RedBlackTree or
is this a todo?
What's the policy on using GC or not in std.container.* ?
- std.container.Array uses malloc for its allocation but
- RedBlackTree.allocate() returns a: new RBNode!Elem*
Is this because RBNode* should be reachable outside of
RedBlackTree or is this a todo?
