On Wednesday, 17 September 2014 at 23:57:03 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
compile-time type information via templates. Ideally it should
be a
fully-decoupled library implementation interfacing with the
compiler via
a set API, but we're still some ways off from that right now.
See our hashmap and hashset implementations here:
https://github.com/economicmodeling/containers/tree/master/src/containers
These containers are all certified GC-free.
I get loads of erros on DMD 2.066:
memory/allocators.d(81,4): Error: pure function
On Thursday, 18 September 2014 at 10:21:29 UTC, Nordlöw wrote:
These containers are all certified GC-free.
I get loads of erros on DMD 2.066:
My mistake. I hade accidentally used another version of
std.allocator.
Have anybody cooked any GC-less variants of hash-tables
(associative arrays) that take keys and values with value
semantics only.
Similar to how
X[]
relates to
std.containers.Array!X
I need this to index my nodes in graphs with tens of millions of
nodes.
On Wednesday, 17 September 2014 at 10:39:07 UTC, Nordlöw wrote:
Have anybody cooked any GC-less variants of hash-tables
(associative arrays) that take keys and values with value
semantics only.
Important follow-up question: If types of key and value all have
value semantics (no indirections)
On Wed, 17 Sep 2014 10:39:05 +, Nordlöw wrote:
Have anybody cooked any GC-less variants of hash-tables (associative
arrays) that take keys and values with value semantics only.
Similar to how
X[]
relates to
std.containers.Array!X
I need this to index my nodes in
On Wednesday, 17 September 2014 at 15:27:40 UTC, Justin Whear
wrote:
These containers are all certified GC-free.
Superb!
One question though:
AFAIK a builtin hash-table in D shouldn't require nor use any
GC-allocations if the keys and values all have reference
semantics right (no string
On Wednesday, 17 September 2014 at 15:27:40 UTC, Justin Whear
wrote:
These containers are all certified GC-free.
What's the difference between std.containers.Array and
DynamicArray? The RC?
On Wednesday, 17 September 2014 at 19:39:16 UTC, Nordlöw wrote:
On Wednesday, 17 September 2014 at 15:27:40 UTC, Justin Whear
wrote:
These containers are all certified GC-free.
What'a the cost of using hashset in favour of hashmap if I want
the to use the
Range range()
property?
On Wed, Sep 17, 2014 at 07:23:01PM +, Nordlöw via Digitalmars-d-learn
wrote:
On Wednesday, 17 September 2014 at 15:27:40 UTC, Justin Whear wrote:
These containers are all certified GC-free.
Superb!
One question though:
AFAIK a builtin hash-table in D shouldn't require nor use any
H. S. Teoh:
How do you implement a completely GC-free AA with no limit on
number of entries stored?
Ada2012 has a fixed-size hash in the standard library, it can
even be allocated on the stack. But the number of entries is not
unlimited.
Bye,
bearophile
On Wednesday, 17 September 2014 at 19:51:06 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
How do you implement a completely GC-free AA with no limit on
number of
entries stored? I mean, where would it get the memory to store
the
hashtable from?
I mean, GC-free not heap-free. An AA of course
On Wed, Sep 17, 2014 at 10:26:16PM +, Nordlöw via Digitalmars-d-learn
wrote:
On Wednesday, 17 September 2014 at 19:51:06 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
How do you implement a completely GC-free AA with no limit on number
of entries stored? I mean, where would it get the
On Wednesday, 17 September 2014 at 22:36:55 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
So you would use malloc/free?
Yes, with GC-free I mean *not* involving D's automatic garbage
collector for the individual allocations of the AA *keys* and
*values*.
How are these normally allocated
On Wed, Sep 17, 2014 at 10:44:17PM +, Nordlöw via Digitalmars-d-learn
wrote:
On Wednesday, 17 September 2014 at 22:36:55 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
So you would use malloc/free?
Yes, with GC-free I mean *not* involving D's automatic garbage
collector for the
On Wednesday, 17 September 2014 at 15:27:40 UTC, Justin Whear
wrote:
These containers are all certified GC-free.
With the exception of getting keys and values arrays. Those
return GC memory to the caller. I'm pretty sure it's documented
that it does that though. Everything else uses
On Wednesday, 17 September 2014 at 23:27:10 UTC, Nordlöw wrote:
to check if we need to use GC. If not we can use malloc/free.
Further if they key and values are all fixed-size we should
probably use some allocator instead of malloc/free. That would
make more efficient use of this allocation
On Wed, Sep 17, 2014 at 11:27:08PM +, Nordlöw via Digitalmars-d-learn
wrote:
On Wednesday, 17 September 2014 at 22:56:17 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
Slots come from the GC heap, but in theory it could come from any
allocator, potentially even malloc/free, since the
On Wed, Sep 17, 2014 at 11:43:27PM +, Nordlöw via Digitalmars-d-learn
wrote:
On Wednesday, 17 September 2014 at 23:27:10 UTC, Nordlöw wrote:
to check if we need to use GC. If not we can use malloc/free.
Further if they key and values are all fixed-size we should probably
use some
19 matches
Mail list logo
