Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Alternate design without separate cursors #53

Open
Diggsey opened this issue Dec 23, 2020 · 1 comment
Open

Suggestion: Alternate design without separate cursors #53

Diggsey opened this issue Dec 23, 2020 · 1 comment

Comments

@Diggsey
Copy link

Diggsey commented Dec 23, 2020

A common reason to use intrusive data-structures is to be able to look up an element via one data-structure, and then perform some operation on the same element in a different data-structure.

AIUI, this cannot be done safely with this crate, as it requires the unsafe cursor_mut_from_ptr method to be called.

I think a safe interface could be made by having this crate own the allocator that produces elements. For example, a basic allocator could store elements in a Vec<T>, and then use Vec indices as the "pointers" used to identify elements. Safety would be ensured by checking indices against the length of the internal Vec.

This would not prevent logic errors (if you mixed elements from different allocators, you'd get garbage results) but it should all be safe.

An arena allocator could work similarly, but using real pointers and range checks instead.

@Amanieu
Copy link
Owner

Amanieu commented Dec 24, 2020

I think this is probably outside the scope of intrusive-collections and should be done in a separate crate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants