| Crates.io | multi_stack_queue |
| lib.rs | multi_stack_queue |
| version | 0.3.0 |
| created_at | 2021-07-03 18:41:47.184292+00 |
| updated_at | 2021-07-09 16:03:53.696654+00 |
| 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"