I have been struggling with variants of this for a while and there's no "best" solution.
First, if the array holds values (as opposed to pointers to values), then pretty much your only option is to replace your pointers with indices to the array. You'd need access to the container to access the values, of course. But this is the only safe way because adding into the array may relocate it, invalidating all pointers. If your array holds pointers, then you can do something; e.g., store Rc<T> in the array cells and also in the places you want to link to the values. If reference cycles are an issue you can use @T instead of Rc<T> (keep in mind this will change to Gc<T> or something in the future). If sending the whole thing is an issue, you are pretty much forced to use Arc<T> (and forget about reference cycles). And, of course, each of these (Rc, @, Arc) has a different name if you want mutation (RcMut, @mut, ArcRW). In performance-critical code I sometimes give up and just have an array of ~T and use an unsafe ptr to T in all my other references... which is OK as long as these only live as long as the container, but I get zero compiler support for that. I wish there was a way to say "this borrowed pointer lives only as long as its container". That doesn't seem to be in the cards though :-( On Tue, Nov 12, 2013 at 2:24 PM, spir <[email protected]> wrote: > Hello Rust people, > > A data structure holds (unpointed) cells in an array. Then, a number of > linked lists part of the data structure link to those same cells. What is > the right Rust way to do that? I cannot have the language accept the > instruction establishing a link, whatever kind of pointer I use (both for > self and for cells). > > Code and/or details on demand. > > Denis > > PS: It is in fact a hash table [1] which buckets are link lists as > usually, but the cells are stored in an array instead of spread around the > memory at the allocator's convenience ;-). First advantage is indeed > entries are in order. > (To move on in the meanwhile, I'll remove this aspect.) > > [1] Actually a "mod table" since keys are uints, there is no hash, only > modulo. > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
