-
Notifications
You must be signed in to change notification settings - Fork 52
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
[slot_map] partition and underlying_swap #131
Comments
Just like the standard `std::partition` algorithm, this member function reorders the slot_map's elements in such a way that all elements for which the predicate `pred` returns `true` precede the elements for which `pred` returns `false`. The relative order of the elements is not preserved. The function returns an iterator to the first element of the second group (which may be `end()`, in the case that all elements belong to the first group). Addresses part of WG21-SG14#131, although I'm not sure whether this really addresses whatever use case @p-groarke is thinking of.
I think the constructor thing should be a separate GitHub issue from the I doubt I understand your |
If I read the partition description correctly, that is the perfect tool for the job. I still believe If you are interested, let me try to clarify expected partition behavior in a game engine using a If you are interested in more game engine oriented details, you can read the bitsquid blog series on his entity component system http://bitsquid.blogspot.com/2014/08/building-data-oriented-entity-system.html. From what I read in the |
I think you're probably right that
I think that's a correct implementation of |
I have no attachment to naming. I'm fine with Initially, I really did think swapping ids was essential. That's why id_swap made sense. For example, having 2 objects with 2 ids, and changing the ids so id1 points to obj2 and id2 points to obj1. I can't rule that out as a desired behavior. I'll open a different issue if I ever have a compelling use case (that would be Concerning To recap :
|
Fixed by #133 |
Just like the standard `std::partition` algorithm, this member function reorders the slot_map's elements in such a way that all elements for which the predicate `pred` returns `true` precede the elements for which `pred` returns `false`. The relative order of the elements is not preserved. The function returns an iterator to the first element of the second group (which may be `end()`, in the case that all elements belong to the first group). Addresses part of WG21-SG14#131, although I'm not sure whether this really addresses whatever use case @p-groarke is thinking of.
Well, I haven't merged #133 yet, so I'm reopening this. But yeah, I have no particular reason to mistrust #133, except for the naming issue. @Masstronaut, are you still interested in |
Just like the standard `std::partition` algorithm, this member function reorders the slot_map's elements in such a way that all elements for which the predicate `pred` returns `true` precede the elements for which `pred` returns `false`. The relative order of the elements is not preserved. The function returns an iterator to the first element of the second group (which may be `end()`, in the case that all elements belong to the first group). Addresses part of WG21-SG14#131, although I'm not sure whether this really addresses whatever use case @p-groarke is thinking of.
Just like the standard `std::partition` algorithm, this member function reorders the slot_map's elements in such a way that all elements for which the predicate `pred` returns `true` precede the elements for which `pred` returns `false`. The relative order of the elements is not preserved. The function returns an iterator to the first element of the second group (which may be `end()`, in the case that all elements belong to the first group). Addresses part of WG21-SG14#131, although I'm not sure whether this really addresses whatever use case @p-groarke is thinking of.
Just like the standard `std::partition` algorithm, this member function reorders the slot_map's elements in such a way that all elements for which the predicate `pred` returns `true` precede the elements for which `pred` returns `false`. The relative order of the elements is not preserved. The function returns an iterator to the first element of the second group (which may be `end()`, in the case that all elements belong to the first group). Addresses part of WG21-SG14#131, although I'm not sure whether this really addresses whatever use case @p-groarke is thinking of.
Just like the standard `std::partition` algorithm, this member function reorders the slot_map's elements in such a way that all elements for which the predicate `pred` returns `true` precede the elements for which `pred` returns `false`. The relative order of the elements is not preserved. The function returns an iterator to the first element of the second group (which may be `end()`, in the case that all elements belong to the first group). Addresses part of WG21-SG14#131, although I'm not sure whether this really addresses whatever use case @p-groarke is thinking of.
When using slot_map for components and such, one would usually implement a disable feature. This is done using a pivot, and swapping disabled elements to the end of your contiguous container. Iterating the "enabled" data will thus be contiguous.
I don't think the standard would ever accept a container with this kind of state. So a way to enable this should be provided. From my uses so far, I think a simple
id_swap(Key old, Key new)
would enable a lot of needed flexibility.For disabling components, one could create 2
slot_maps
, enabled and disabled, and move objects between the 2. The only problem then is users will have copies of the original id. Addingid_swap
lets you move into a disabledslot_map
, swap the id to the old one, never invalidating user owned ids.There are other uses for
id_swap
. When using RAII to keep user ids valid, the copy constructor would need such a thing.Ultimately, you want to keep iterators valid when moving/swapping/deleting objects.
id_swap
is just an idea, there may be better ways.The text was updated successfully, but these errors were encountered: