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.
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
'memory.allocators.BlockAllocator!1024LU.B
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.
I
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
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 t
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 r
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 allocator
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 lifetime of
the Slots
So I guess there is room for some optimizations here right?
We
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 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 in
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
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
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 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
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 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 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 cla
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 n
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)
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.
20 matches
Mail list logo
