#pool #index #allocator #vec #pin

no-std indexed

Convenient allocator for index-linked data structures

3 unstable releases

Uses old Rust 2015

0.2.0 Feb 20, 2020
0.1.1 Nov 9, 2018
0.1.0 Oct 24, 2018

#342 in Memory management

Download history 367/week @ 2024-01-10 235/week @ 2024-01-17 277/week @ 2024-01-24 136/week @ 2024-01-31 285/week @ 2024-02-07 266/week @ 2024-02-14 360/week @ 2024-02-21 307/week @ 2024-02-28 413/week @ 2024-03-06 344/week @ 2024-03-13 515/week @ 2024-03-20 323/week @ 2024-03-27 420/week @ 2024-04-03 549/week @ 2024-04-10 360/week @ 2024-04-17 319/week @ 2024-04-24

1,710 downloads per month

MIT license

355 lines

The indexed::Pool, a convenient allocator for index-linked data structures.


  1. Vec-like operations.

Supports push(), reserve() and random access by indexes which are similar with std::Vec's methods.

An unsafe write() method is provided, similar with std::ptr::write() except using index instead of pointer.

Other stuff like len(), set_len(), capacity(), iter() and iter_mut()` are also supported. See API doc for more.

Note that all deleting operations e.g. pop(), shrink_to_fit() are not supported.

  1. Using indexes to link elements to each other.

Any element in the pool must implement indexed::Indexed, which stores its index in itself. A user-defined null() index indicates an empty linkage.

  1. Obtaining reference of the pool from any one of its elements.

This feature makes it possible to simply use reference of element instead of the style of using pool + index. It is convenient in some usecases because the library users do not need to store/pass the references of the pool everywhere.

NOTICE: this feature is unsafe and it is up to the caller not to violating memory safety.

  1. No reallocation will happen.

Once an element is located in the pool, it will not move at all.

  1. The pool can be managed or unmanaged.

A managed pool owns its elements and drops them in destruction while an unmanaged pool does not.

  1. Supports no_std.


  1. The underlying buffers are not continuous but segmented Vecs. Mapping conceptual index to underlying buffer address is as lightweight as doing one integer division.

  2. Elements should provide space for storing their indexes. Index stored in usize occupies one extra pointer size. Index stored in u32 may occupy no extra space if some 32-bit padding exists in the struct in order to meet alignment requirement.

  3. Obtaining the pool's reference from its element is as efficient as one pointer arithmetic and deference operation. Library users can pick the classic pool + index API style if not satisfied with this overhead.

  4. Library users can pick up a different chunk size other than the default 256 for better performance.


Licensed under MIT.


See API doc for more.

No runtime deps