Crates.io | multi_stack_queue |
lib.rs | multi_stack_queue |
version | 0.3.0 |
source | src |
created_at | 2021-07-03 18:41:47.184292 |
updated_at | 2021-07-09 16:03:53.696654 |
description | Abstraction layer for a stack-allocated multi-queue with bounded length. WIP |
homepage | |
repository | https://github.com/Sup3Legacy/multi_stack_queue |
max_upload_size | |
id | 418284 |
size | 14,003 |
A crate for stack-allocated fixed-length multiqueues. A multiqueue is an array of a given number of queues, each able to be accessed independently.
Based on an original idea from Pollux3737.
The generic definition is the following :
MultiStackQueue<T, const N: usize, const M: usize>
With :
T
- type contained in the queuesN
- length of each queueM
- number of queuesuse multi_stack_queue::MultiStackQueue;
#[derive(Debug, PartialEq, Eq)]
struct TestStruct {
a: usize,
b: bool,
}
let mut msq: MultiStackQueue<TestStruct, 16, 8> = MultiStackQueue::new();
let value = TestStruct { a: 42, b: false };
msq.push(7, value).unwrap();
assert_eq!(msq.pop(7).unwrap(), value);
[X] Using arrays of Option<T>
requires that T
implements the Copy
trait, which may not be the case. A different approach is to use default values instead of Option::None
to initialize the arrays. This way, T
must need not implement Copy
but Default
, which may be beneficial in some usecases. Another idea would be to make use of the MaybeUnInit
type.
[X] Add options in the generic definition of MultiStackQueue
to enable the user to specify the procedure in case of a push
on a full queue or a pop
on an empty queue. For instance, one could wish trying to push an element to a full queue would simply push it to the following queue (and same thing when trying to pop
an element). This would add a sort of "spill mechanism"