genmap

Crates.iogenmap
lib.rsgenmap
created_at2019-09-02 05:13:45.008634
updated_at2020-11-23 05:14:49.270877
descriptionA simple generational map data structure with no dependencies.
homepage
repositoryhttps://hg.sr.ht/~icefox/genmap
max_upload_size
id161500

documentation

README

# genmap A Rust crate for a generational map, handle map, whatever you want to call it. Whatever it is, this is a random-access data structure that stores an unordered bag of items and gives you a handle for each specific item you insert. Looking things up by handle is `O(1)` -- the backing storage is just a `Vec` -- and items can be removed as well, which is also `O(1)`. Handles are small (two `usize`'s) and easy to copy, similar to a slice. The trick is that there is a generation number stored with each item, so that a "dangling" handle that refers to an item that has been removed is invalid. Unlike array indices, if you remove an item from the array and a new one gets put in its place, the old stale handle does not refer to the new one and trying to use it will fail at runtime. This is useful for various things: managing lots of uniform things with shared ownership (such as video game resources), interning strings, that sort of thing. Essentially by using handles to items you have runtime-checked memory safety: you can get an item from the map using the handle, since it's basically just an array index. In practice this is not unrelated to `Rc`, it's just that `Rc` does the accounting of memory on cloning the `Rc`, and this does it on "dereferencing" by looking up an object's handle. Referencing counting, threading garbage collection and this sort of map are all different methods of achieving the same thing (checking for memory safety at runtime) with different tradeoffs. With a reference count you don't have to explicitly free items and can't have stale handles, but loops require special handling and you pay for the accounting cost on cloning a handle. With this you have to free items explicitly, but stale handles can be safely detected and the accounting happens when you look the item up. You can also use it as a slab allocator type thing, where you pre-allocate a large amount of storage and free it all at once. # Limitations * It never frees memory until the `GenMap` is dropped (though it does reuse empty slots). * Overflowing generations is an error. Should it be a u64 rather than usize? # Other things like this: * `generational-arena` -- I couldn't find this and so wrote `genmap` * instead. You should probably just use `generational-arena`. * `slotmap` -- requires your items be `Copy`, which I feel is too restrictive. Its `DenseSlotMap` gets around this, but really at that point there's too many options and tradeoffs to consider. I just want something that Works. * `handy` -- Nice but I don't like some of the design decisions it makes: * `slab` -- Not really a generational map IMO, since it doesn't track generations. * `specs` -- A Storage in `specs` is basically a type of generational map. `specs` adds tons of other stuff though. # License MIT/Apache-2.0
Commit count: 0

cargo fmt