[Issue 11781] gc collections run even when disabled

https://issues.dlang.org/show_bug.cgi?id=11781 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --

[Issue 15084] GC must ensure there is at least X% of free space in the heap after collection to avoid frequent collections

https://issues.dlang.org/show_bug.cgi?id=15084 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --

Re: Collections in D

On Wednesday, 13 January 2021 at 12:06:05 UTC, Roguish wrote: which seems perfectly adequate. What about sets? You can also search https://code.dlang.org I use: https://code.dlang.org/packages/emsi_containers Which has hashset:

Re: Collections in D

On Wednesday, 13 January 2021 at 12:39:50 UTC, evilrat wrote: There is no specific set container, they just implemented as generic algorithms over the ranges. I see. Thanks for pointing that out.

Re: Collections in D

On Wednesday, 13 January 2021 at 12:48:47 UTC, Ferhat Kurtulmuş wrote: I read many posts that rbtree can be a replacement for sets in dlang. see its behaviour is identical. Thanks, will read up.

Re: Collections in D

On Wednesday, 13 January 2021 at 12:06:05 UTC, Roguish wrote: On Wednesday, 13 January 2021 at 11:58:11 UTC, Roguish wrote: I can't find anything about collections in D. All I have found are arrays and maps ("associative arrays"). What about lists and sets? What if I just want a l

Re: Collections in D

On Wednesday, 13 January 2021 at 12:06:05 UTC, Roguish wrote: What about sets? There is no specific set container, they just implemented as generic algorithms over the ranges. There is a section for set operations (std.algorithm.setops module). https://dlang.org/phobos/std_algorithm.html

Re: Collections in D

On Wednesday, 13 January 2021 at 11:58:11 UTC, Roguish wrote: I can't find anything about collections in D. All I have found are arrays and maps ("associative arrays"). What about lists and sets? What if I just want a linked list? It seems collections are called "containers&q

Re: Collections in D

On Wednesday, 13 January 2021 at 11:58:11 UTC, Roguish wrote: I can't find anything about collections in D. All I have found are arrays and maps ("associative arrays"). What about lists and sets? What if I just want a linked list? You can refer to the docs for them: https://dlang.

Collections in D

I can't find anything about collections in D. All I have found are arrays and maps ("associative arrays"). What about lists and sets? What if I just want a linked list?

Re: Runtime heterogeneous collections?

I'd like to thank everyone for their help! I was finally able to do what I'd like. I didn't end up using a variant, but maybe there's a better way to do what I want using it, and I just couldn't figure it out. Here's the solution I finally came up with: https://run.dlang.io/is/GdDDBp If

Re: Runtime heterogeneous collections?

s Rec_type2 = Tuple!(int, "x", int, "y", string, "z"); Tuple!(RedBlackTree!Rec_type1, "x", RedBlackTree!Rec_type2, "z") test; Similar questions were asked before, usually such heterogeneous collections are not the best solution to the problem at hand.

Re: Runtime heterogeneous collections?

On Friday, 18 January 2019 at 15:07:41 UTC, Steven Schveighoffer wrote: On 1/18/19 9:58 AM, Alex wrote: On Friday, 18 January 2019 at 13:31:28 UTC, Steven Schveighoffer wrote: [...] In this case, I would say Phobos lacks an appropriate interface definition, what do you think? But what is

Re: Runtime heterogeneous collections?

On 1/18/19 10:10 AM, Neia Neutuladh wrote: On Fri, 18 Jan 2019 10:07:41 -0500, Steven Schveighoffer wrote: But what is the common interface between those 2 types? Even in Dcollections, where RedBlackTree came from, there was no interfaces that didn't specify the type they were dealing with. In

Re: Runtime heterogeneous collections?

On Fri, 18 Jan 2019 10:07:41 -0500, Steven Schveighoffer wrote: > But what is the common interface between those 2 types? Even in > Dcollections, where RedBlackTree came from, there was no interfaces that > didn't specify the type they were dealing with. In other words, there is > no common

Re: Runtime heterogeneous collections?

On 1/18/19 9:58 AM, Alex wrote: On Friday, 18 January 2019 at 13:31:28 UTC, Steven Schveighoffer wrote: To answer the OP, what he wants is an array of different RedBlackTrees. Since RedBlackTree is a class, his code is not far off from something that works. This does compile, and produces an

Re: Runtime heterogeneous collections?

On Friday, 18 January 2019 at 13:31:28 UTC, Steven Schveighoffer wrote: To answer the OP, what he wants is an array of different RedBlackTrees. Since RedBlackTree is a class, his code is not far off from something that works. This does compile, and produces an Object[]: auto arr = [

Re: Runtime heterogeneous collections?

On 1/17/19 11:06 PM, Jonathan M Davis wrote: On Thursday, January 17, 2019 1:21:41 AM MST Dukc via Digitalmars-d-learn wrote: On Thursday, 17 January 2019 at 02:27:20 UTC, Neia Neutuladh wrote: 1. Make a wrapper class. Now you can store Object[], or you can make a base class or base interface

Re: Runtime heterogeneous collections?

On Thursday, January 17, 2019 1:21:41 AM MST Dukc via Digitalmars-d-learn wrote: > On Thursday, 17 January 2019 at 02:27:20 UTC, Neia Neutuladh > > wrote: > > 1. Make a wrapper class. Now you can store Object[], or you can > > make a > > base class or base interface and use that. > > 2. Use

Re: Runtime heterogeneous collections?

On Thursday, 17 January 2019 at 02:27:20 UTC, Neia Neutuladh wrote: On Thu, 17 Jan 2019 02:21:21 +, Steven O wrote: I want to create a heterogeneous collection of red-black trees, and I can't seem to figure out if it's possible. RedBlackTree!int and RedBlackTree!string are entirely

Re: Runtime heterogeneous collections?

On Thursday, 17 January 2019 at 02:27:20 UTC, Neia Neutuladh wrote: 1. Make a wrapper class. Now you can store Object[], or you can make a base class or base interface and use that. 2. Use Variant, which can wrap anything, or the related Algebraic, which can wrap a fixed collection of types.

Re: Runtime heterogeneous collections?

On Thu, 17 Jan 2019 02:21:21 +, Steven O wrote: > I want to create a heterogeneous collection of red-black trees, and I > can't seem to figure out if it's possible. RedBlackTree!int and RedBlackTree!string are entirely different types (they just happen to be generated from the same

Runtime heterogeneous collections?

I want to create a heterogeneous collection of red-black trees, and I can't seem to figure out if it's possible. I can easily do: import std.container.rbtree; import std.typecons; void main() { alias Rec_type = Tuple!(int, "x", int, "y", int, "z"); RedBlackTree!Rec_type[1] test; }

Re: On "A New Collections Framework for the Standard Library"

On 11/13/2017 05:19 AM, Mark wrote: On Thursday, 18 May 2017 at 18:27:22 UTC, Andrei Alexandrescu wrote: On 05/18/2017 11:18 AM, Jack Stouffer wrote: I just got around to watching Eduard Staniloiu's talk at DConf [1] about the collections library he was working on. One thing seemed odd

Re: On "A New Collections Framework for the Standard Library"

On Thursday, 18 May 2017 at 18:27:22 UTC, Andrei Alexandrescu wrote: On 05/18/2017 11:18 AM, Jack Stouffer wrote: I just got around to watching Eduard Staniloiu's talk at DConf [1] about the collections library he was working on. One thing seemed odd, in that Eduard seems to be saying

Re: On "A New Collections Framework for the Standard Library"

On Friday, May 19, 2017 1:22:50 AM PDT Jack Stouffer via Digitalmars-d wrote: > First off, how are you going to do something like a map over a > immutable container then, as map uses the range primitives and > not foreach? There's no reason in principal that that should > cause an issue. But with

Re: On "A New Collections Framework for the Standard Library"

On Thursday, 18 May 2017 at 15:18:00 UTC, Jack Stouffer wrote: I just got around to watching Eduard Staniloiu's talk at DConf [1] about the collections library he was working on. One thing seemed odd, in that Eduard seems to be saying that the container and the range over the container's

Re: On "A New Collections Framework for the Standard Library"

On Thursday, 18 May 2017 at 18:27:22 UTC, Andrei Alexandrescu wrote: Iterating over a container using e.g. foreach won't consume the container same as iterating over int[] won't consume the slice. I don't understand why you're mapping the behavior of ranges/slices, which theoretically are

Re: On "A New Collections Framework for the Standard Library"

On 05/18/2017 02:17 PM, Jack Stouffer wrote: On Thursday, 18 May 2017 at 15:18:00 UTC, Jack Stouffer wrote: ... Also, shared allocators raise another problem entirely. Let's say for the sake of clarity that these future containers will use a separate range type. Let's say you have a

Re: On "A New Collections Framework for the Standard Library"

On 05/18/2017 11:18 AM, Jack Stouffer wrote: I just got around to watching Eduard Staniloiu's talk at DConf [1] about the collections library he was working on. One thing seemed odd, in that Eduard seems to be saying that the container and the range over the container's elements are one

Re: On "A New Collections Framework for the Standard Library"

On Thursday, 18 May 2017 at 15:18:00 UTC, Jack Stouffer wrote: ... Also, shared allocators raise another problem entirely. Let's say for the sake of clarity that these future containers will use a separate range type. Let's say you have a container with five elements, and then you give a

Re: On "A New Collections Framework for the Standard Library"

On Thursday, 18 May 2017 at 15:38:39 UTC, Jonathan M Davis wrote: That point concerned me as well. Dynamic arrays in D are very strange beasts indeed, and while it works for them to function as both ranges and (sort of) containers, it's also created a fair bit of confusion, and it really a

Re: On "A New Collections Framework for the Standard Library"

On Thursday, May 18, 2017 15:18:00 Jack Stouffer via Digitalmars-d wrote: > I just got around to watching Eduard Staniloiu's talk at DConf > [1] about the collections library he was working on. One thing > seemed odd, in that Eduard seems to be saying that the container > and th

On "A New Collections Framework for the Standard Library"

I just got around to watching Eduard Staniloiu's talk at DConf [1] about the collections library he was working on. One thing seemed odd, in that Eduard seems to be saying that the container and the range over the container's elements are one in the same and the range primitives

Re: Collections question

On 12/02/2015 01:45 AM, deadalnix wrote: On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei Alexandrescu wrote: Ah, the good old assignment to reference. We need to prevent that from happening in safe code. Got any fresh ideas? -- Andrei Disable owner when borrowing 'mutably', and not when

Re: Collections question

On Wednesday, 2 December 2015 at 15:58:19 UTC, Andrei Alexandrescu wrote: On 12/02/2015 01:45 AM, deadalnix wrote: On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei Alexandrescu wrote: Ah, the good old assignment to reference. We need to prevent that from happening in safe code. Got any

Re: Collections question

On Wednesday, 2 December 2015 at 06:45:33 UTC, deadalnix wrote: On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei Alexandrescu wrote: Ah, the good old assignment to reference. We need to prevent that from happening in safe code. Got any fresh ideas? -- Andrei Disable owner when borrowing

Re: Collections question

On Wednesday, 2 December 2015 at 06:45:33 UTC, deadalnix wrote: On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei Alexandrescu wrote: Ah, the good old assignment to reference. We need to prevent that from happening in safe code. Got any fresh ideas? -- Andrei Disable owner when borrowing

Re: Collections question

On Wednesday, 2 December 2015 at 15:58:19 UTC, Andrei Alexandrescu wrote: On 12/02/2015 01:45 AM, deadalnix wrote: On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei Alexandrescu wrote: Ah, the good old assignment to reference. We need to prevent that from happening in safe code. Got any

Re: Collections question

On 12/01/2015 09:35 AM, Marc Schütz wrote: On Tuesday, 1 December 2015 at 14:15:47 UTC, Andrei Alexandrescu wrote: On 12/1/15 4:55 AM, Marc Schütz wrote: On Monday, 30 November 2015 at 18:18:38 UTC, Andrei Alexandrescu wrote: * The one matter with the value/RefCounted approach is that

Re: Collections question

On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei Alexandrescu wrote: Ah, the good old assignment to reference. We need to prevent that from happening in safe code. Got any fresh ideas? -- Andrei Disable owner when borrowing 'mutably', and not when borrowing 'constly'.

Re: Collections question

On Monday, 30 November 2015 at 18:18:38 UTC, Andrei Alexandrescu wrote: * The one matter with the value/RefCounted approach is that RefCounted cannot be made @safe. That's just as true for internal refcounting.

Re: Collections question

On Tuesday, 1 December 2015 at 14:15:47 UTC, Andrei Alexandrescu wrote: On 12/1/15 4:55 AM, Marc Schütz wrote: On Monday, 30 November 2015 at 18:18:38 UTC, Andrei Alexandrescu wrote: * The one matter with the value/RefCounted approach is that RefCounted cannot be made @safe. That's just as

Re: Collections question

On 12/1/15 4:55 AM, Marc Schütz wrote: On Monday, 30 November 2015 at 18:18:38 UTC, Andrei Alexandrescu wrote: * The one matter with the value/RefCounted approach is that RefCounted cannot be made @safe. That's just as true for internal refcounting. I don't think that's the case. The way I

Re: Collections question

On Monday, 30 November 2015 at 16:06:43 UTC, Steven Schveighoffer wrote: MyCollection!(int) c1; auto c2 = c1; c1 ~= 1; assert(c2.contains(1)); // pass? fail? BTW, I third Jonathan's and Timon's suggestion -- go with an external factory function. Use IFTI to its fullest! -Steve That should

Re: Collections question

On 11/30/15 11:21 AM, Tobias Pankrath wrote: On Monday, 30 November 2015 at 16:06:43 UTC, Steven Schveighoffer wrote: MyCollection!(int) c1; auto c2 = c1; c1 ~= 1; assert(c2.contains(1)); // pass? fail? BTW, I third Jonathan's and Timon's suggestion -- go with an external factory function.

Re: Collections question

later on. Fast-forward to general collections. If we want to support things like reference containers, clearly that oddity must be addressed. There are two typical approaches: 1. Factory function: struct MyCollection(T) { static MyCollection make(U...)(auto ref U args); ... } So

Re: Collections question

On Saturday, 28 November 2015 at 13:39:35 UTC, Andrei Alexandrescu wrote: On 11/28/15 1:59 AM, bitwise wrote: Classes/real-ref-types dont act as you're describing, so why should these fake struct wrapper ref things act this way? This will likely achieve the exact opposite of what you're

Re: Collections question

On 11/30/2015 12:56 PM, bitwise wrote: On Saturday, 28 November 2015 at 13:39:35 UTC, Andrei Alexandrescu wrote: On 11/28/15 1:59 AM, bitwise wrote: Classes/real-ref-types dont act as you're describing, so why should these fake struct wrapper ref things act this way? This will likely achieve

Re: Collections question

On Sunday, 29 November 2015 at 15:06:49 UTC, Andrei Alexandrescu wrote: Thanks all. I'll go with the factory function. -- Andrei As Timon suggested, I'd encourage you to go for a free factory function named after the container like RedBlackTree does with redBlackTree rather than having a

Re: Collections question

On 11/29/15 5:06 AM, Atila Neves wrote: On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu wrote: There's this oddity of built-in hash tables: a reference to a non-empty hash table can be copied and then both references refer to the same hash table object. However, if the hash

Re: Collections question

On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu wrote: There's this oddity of built-in hash tables: a reference to a non-empty hash table can be copied and then both references refer to the same hash table object. However, if the hash table is null, copying the reference won't

Re: Collections question

On 11/28/15 2:26 AM, Jakob Ovrum wrote: Another thing: wouldn't providing a custom allocator require a separate primitive? All collections will work with IAllocator. -- Andrei

Re: Collections question

track the same object later on. Fast-forward to general collections. [...] Andrei I'd prefer the factory method and we shouldn't allow lazy initialization. That's only confusing, if it sometimes works and sometimes won't work. Null container should throw.

Re: Collections question

On 11/28/15 1:59 AM, bitwise wrote: Classes/real-ref-types dont act as you're describing, so why should these fake struct wrapper ref things act this way? This will likely achieve the exact opposite of what you're aiming for, by making something that's supposed to act like a reference type have

Re: Collections question

track the same object later on. Fast-forward to general collections. If we want to support things like reference containers, clearly that oddity must be addressed. There are two typical approaches: 1. Factory function: struct MyCollection(T) { static MyCollection make(U...)(auto ref U

Re: Collections question

later on. Fast-forward to general collections. If we want to support things like reference containers, clearly that oddity must be addressed. There are two typical approaches: 1. Factory function: ... 2. The opCall trick: ... 3. (Non-internal) factory function: auto c1 = myCollection(1,2,3

Re: Collections question

On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu wrote: 1. Factory function: 2. The opCall trick: 1. Factory Shouldn't opCall be used when you want something to (only) behave as a function? E.g. functors.

Re: Collections question

Factory please. Static opCall has always been nothing but trouble in my experience.

Re: Collections question

On Saturday, 28 November 2015 at 18:38:37 UTC, Kagamin wrote: Well... doesn't work: http://dpaste.dzfl.pl/2c69cc3584b8 I don't understand... of course you can't call what is returned by makeEmpty.

Re: Collections question

On Saturday, 28 November 2015 at 06:26:03 UTC, Jakob Ovrum wrote: On Friday, 27 November 2015 at 20:25:12 UTC, Adam D. Ruppe wrote: That syntax is the same as constructors... if that's what you want it to look like, we ought to actually use a constructor for all but the zero-argument ones

Re: Collections question

On Saturday, 28 November 2015 at 12:20:36 UTC, Timon Gehr wrote: 3. (Non-internal) factory function: auto c1 = myCollection(1,2,3); auto c2 = myCollection!int(); auto c3 = c2; // refers to the same collection as c2 Yeah. In general, I prefer that approach. It's what we currently do with

Re: Collections question

On Saturday, 28 November 2015 at 18:43:33 UTC, Adam D. Ruppe wrote: On Saturday, 28 November 2015 at 18:38:37 UTC, Kagamin wrote: Well... doesn't work: http://dpaste.dzfl.pl/2c69cc3584b8 I don't understand... of course you can't call what is returned by makeEmpty. Recently someone

Re: Collections question

On Saturday, 28 November 2015 at 13:41:10 UTC, Andrei Alexandrescu wrote: On 11/28/15 2:26 AM, Jakob Ovrum wrote: Another thing: wouldn't providing a custom allocator require a separate primitive? All collections will work with IAllocator. -- Andrei Yes, I assumed as much. So how would

Collections question

There's this oddity of built-in hash tables: a reference to a non-empty hash table can be copied and then both references refer to the same hash table object. However, if the hash table is null, copying the reference won't track the same object later on. Fast-forward to general collections

Re: Collections question

On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu wrote: There's this oddity of built-in hash tables: a reference to a non-empty hash table can be copied and then both references refer to the same hash table object. However, if the hash table is null, copying the reference won't

Re: Collections question

On Friday, 27 November 2015 at 20:25:12 UTC, Adam D. Ruppe wrote: That syntax is the same as constructors... if that's what you want it to look like, we ought to actually use a constructor for all but the zero-argument ones which I'd use a static named function for (perhaps .make or perhaps

Re: Collections question

On Saturday, 28 November 2015 at 06:59:35 UTC, bitwise wrote: Classes/real-ref-types dont act as you're describing They do, actually. class Collection(E) { ... } Collection!E a; // null reference auto b = new Collection!E(); // reference to empty collection The only outlier is the

Re: Collections question

track the same object later on. Fast-forward to general collections. If we want to support things like reference containers, clearly that oddity must be addressed. There are two typical approaches: 1. Factory function: struct MyCollection(T) { static MyCollection make(U...)(auto ref U

Re: Collections question

On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu wrote: There's some experience in various libraries with both approaches. Which would you prefer? Well, I think we should recognize that they're the same thing but with different names. I don't have a strong preference for

Re: Collections question

On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu wrote: There's some experience in various libraries with both approaches. Which would you prefer? Another thing: wouldn't providing a custom allocator require a separate primitive? I am assuming that the allocator type won't be

Re: Collections question

On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu wrote: There's this oddity of built-in hash tables: a reference to a non-empty hash table can be copied and then both references refer to the same hash table object. However, if the hash table is null, copying the reference won't

Re: Collections question

On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu wrote: 1. Factory function: This is my preference for zero arg at least because the opCall thing is commonly misunderstood and confused with C++ default construction and we don't need to encourage that. static

[Issue 15084] GC must ensure there is at least X% of free space in the heap after collection to avoid frequent collections

https://issues.dlang.org/show_bug.cgi?id=15084 Vladimir Panteleev changed: What|Removed |Added CC||c...@dawg.eu,

[Issue 15084] New: GC must ensure there is at least X% of free space in the heap after collection to avoid frequent collections

https://issues.dlang.org/show_bug.cgi?id=15084 Issue ID: 15084 Summary: GC must ensure there is at least X% of free space in the heap after collection to avoid frequent collections Product: D Version: D2

Re: Template Collections of Different Types

On Sunday, 16 August 2015 at 02:42:18 UTC, BBasile wrote: --- enum Ti {tibyte, tiubyte, ...} Ti getTypeInfo(T)(T t){statif is(t == ubyte) return Ti.tibyte; else...} You could also just use D's own run time typeinfo with the typeid() thing. It returns an instance of class TypeInfo. (This is

Re: Template Collections of Different Types

On Sunday, 16 August 2015 at 01:39:54 UTC, DarthCthulhu wrote: Say I want to do something like: Propertery!int pi = 42; PropertyCollection pc; pc.attach(Life_and_Everything, pi); assert(pc.Life_and_Everything == 42); Property!string ps = Hello World; pc.attach(text, ps); assert(pc.text ==

Re: Template Collections of Different Types

On Sunday, 16 August 2015 at 01:51:36 UTC, Adam D. Ruppe wrote: On Sunday, 16 August 2015 at 01:39:54 UTC, DarthCthulhu wrote: How would one store the Property objects in the PropertyCollection? You don't, not like that anyway. The attach call is the ruin of it. If it was all one definition,

Template Collections of Different Types

Say I want to do something like: Propertery!int pi = 42; PropertyCollection pc; pc.attach(Life_and_Everything, pi); assert(pc.Life_and_Everything == 42); Property!string ps = Hello World; pc.attach(text, ps); assert(pc.text == Hello World); How would one store the Property objects in the

Re: Template Collections of Different Types

On Sunday, 16 August 2015 at 01:39:54 UTC, DarthCthulhu wrote: How would one store the Property objects in the PropertyCollection? You don't, not like that anyway. The attach call is the ruin of it. If it was all one definition, you could use something like std.typecons.Tuple, but multiple

Rust lifetimes and collections [OT]

It shows the tradeoffs of static enforcement of memory safety in Rust: http://cglab.ca/~abeinges/blah/rust-lifetimes-and-collections/ Some quotations: However it's fairly easy to make an incorrect program by overflowing an integer. Some would therefore assert that it should be unsafe to add

Re: Rust lifetimes and collections [OT]

On 11/19/14 8:54 AM, bearophile wrote: This is nice: fn split_at_mut(mut self, mid: uint) - (mut [T], mut [T]); Bye, bearophile Why did this redditor say it's a horrific hack? http://www.reddit.com/r/programming/comments/2mqyd3/rust_lifetimes_and_collections/cm6yj7b Andrei

Re: Rust lifetimes and collections [OT]

On Wednesday, 19 November 2014 at 17:58:01 UTC, Andrei Alexandrescu wrote: On 11/19/14 8:54 AM, bearophile wrote: This is nice: fn split_at_mut(mut self, mid: uint) - (mut [T], mut [T]); Bye, bearophile Why did this redditor say it's a horrific hack?

Re: Rust lifetimes and collections [OT]

On Wednesday, 19 November 2014 at 17:58:01 UTC, Andrei Alexandrescu wrote: On 11/19/14 8:54 AM, bearophile wrote: This is nice: fn split_at_mut(mut self, mid: uint) - (mut [T], mut [T]); Bye, bearophile Why did this redditor say it's a horrific hack?

Re: Rust lifetimes and collections [OT]

Andrei Alexandrescu: Why did this redditor say it's a horrific hack? http://www.reddit.com/r/programming/comments/2mqyd3/rust_lifetimes_and_collections/cm6yj7b For me it's a nice construct, it's something unsafe that the compiler has to assume for correct. In a language, unless you want a

[Issue 11781] New: gc collections run even when disabled

https://d.puremagic.com/issues/show_bug.cgi?id=11781 Summary: gc collections run even when disabled Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component

[Issue 11781] gc collections run even when disabled

https://d.puremagic.com/issues/show_bug.cgi?id=11781 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com ---

Collections

Last I heard, collection design was delayed while waiting for the allocator design. But I guess there are plenty of collection implementations already. So where are they? o Phobos: std.container - RedBlackTree, BinaryHeap, Array, SList, DList o DCollections: Not updated in 4 years - dead? o

Re: Collections

On 2013-10-19 15:00, simendsjo wrote: Last I heard, collection design was delayed while waiting for the allocator design. But I guess there are plenty of collection implementations already. So where are they? o Phobos: std.container - RedBlackTree, BinaryHeap, Array, SList, DList o

Re: Collections

On Saturday, October 19, 2013 15:00:54 simendsjo wrote: o DCollections: Not updated in 4 years - dead? It's not dead, and it's been updated more recently than 4 years ago (though it was still 2 years ago). The latest should be here https://github.com/schveiguy/dcollections Steven hasn't time

Re: Collections

On 12/03/2013 11:57, ZILtoid1991 wrote: Is there any equaliaments of java collections in D? Different collections that are part of the Java API have different D equivalents. For lists, vectors and stacks, arrays (with their increased power over C, Java, etc. arrays) are more or less the D

Re: Collections

On Tuesday, 12 March 2013 at 11:57:29 UTC, ZILtoid1991 wrote: Is there any equaliaments of java collections in D? https://github.com/Domain/java/tree/master/java

Re: Collections

On Tuesday, 12 March 2013 at 12:02:03 UTC, Zhenya wrote: On Tuesday, 12 March 2013 at 11:57:29 UTC, ZILtoid1991 wrote: Is there any equaliaments of java collections in D? https://github.com/Domain/java/tree/master/java Oh sorry,it seems to be unfinished.

Re: Collections

On Tue, 12 Mar 2013 07:57:24 -0400, ZILtoid1991 ziltoidtheomnic...@gmail.com wrote: Is there any equaliaments of java collections in D? http://www.dsource.org/projects/dcollections I also have created a github project for it, but all I did was import, I haven't done any work besides

Re: Does D have structural sharing of immutable collections?

On Thursday, 24 May 2012 at 01:00:52 UTC, Jonathan M Davis wrote: As part of my thesis work, I wrote a program which was counting possible tokens in code (as part of an AI attempting to learn about a programming language), which required a map of tokens to the number of times that they'd been

Re: Does D have structural sharing of immutable collections?

On Wednesday, 23 May 2012 at 21:12:04 UTC, Jonathan M Davis wrote: On Wednesday, May 23, 2012 20:51:31 Roman D. Boiko wrote: On Wednesday, 23 May 2012 at 18:39:02 UTC, Stewart Gordon wrote: On 23/05/2012 16:05, Roman D. Boiko wrote: snip I need some immutable collections for my D Compiler

Re: Does D have structural sharing of immutable collections?

On Wednesday, 23 May 2012 at 22:39:33 UTC, Roman D. Boiko wrote: On Wednesday, 23 May 2012 at 22:25:35 UTC, Steven Schveighoffer wrote: I looked up how it could be done, the one thing I was not sure of was the parent node. If you can have multiple references to the same subtree, how do you

Re: Does D have structural sharing of immutable collections?

On Thursday, 24 May 2012 at 13:15:30 UTC, Craig Dillabaugh wrote: I am not sure if I entirely understand your problem, but would a persistent search tree work? See: http://www.sciencedirect.com/science/article/pii/002289900342 I have a small write up on them from a course I took years ago:

Does D have structural sharing of immutable collections?

Just some beginner questions... Does D have structural sharing of its immutable collections? i.e. Can I make a copy of an immutable Map or List collection with an extra (or mutated) member, and will the returned (new) collection share most of it's structure with the earlier collection

Re: Does D have structural sharing of immutable collections?

Chris Dew: Does D have structural sharing of its immutable collections? i.e. Can I make a copy of an immutable Map or List collection with an extra (or mutated) member, and will the returned (new) collection share most of it's structure with the earlier collection. Currently Phobos

  1   2   >