Entt: Little question about destroying entities

[Milerius]

Hello, I am not yet at this stage in my project. But I was wondering what happens if I destroy an entity when I loop over my entities. Like when we destroy an element of a vector while we are looping over it for example.

[skypjack]

You can safely modify (assign/remove components) or destroy the entity currently returned by a view/iterator. You can also create entities and assigns components during iterations.
In other terms, this is perfectly valid code:

registry.view<C1, C2>().each([&registry](const auto entity, auto &&...) {
    registry.destroy(entity);
});

Similarly, also the following example works just fine:

for(const auto entity: registry.view<C1, C2>()) {
    registry.destroy(entity);
}

On the other side, there are no guarantees if you delete an entity that isn't the one returned by the entity. In other terms, this could result in unexpected behaviors:

registry.view<Parent>().each([&registry](const auto entity, const auto &parent) {
    registry.destroy(parent.child);
});

More details about this topic are already present in the README file.

[danielytics]

@skypjack Not really about destroying entities while iterating, but rather about adding them, so semi-related:

Iterators are invalidated and the behavior is undefined if an entity is modified or destroyed and it's not the one currently returned by the view.

So, does this mean that if I create a new entity during iteration, I can't add any components to it at that point since adding components to the new entity would count as modifying it (I need to instead store the entity and add its components after iterating through the view)?

Basically, I want to confirm that if you add a new entity while iterating a view, it will not appear in that loop since its not valid to add components to it while iterating the view and since it won't have the components needed by the view, there's no way it can appear in the view at this time.

[skypjack]

@danielytics Not exactly. I should rather review that statement, it's confusing.
If you have any suggestions on how to rewrite it, please help me. I'm not a native speaker and it happens that I fail to properly describe something.

In fact, when you iterate a view, you can create how many entities you want and assign them the components you want. It was one of the first requirement I set when I started writing EnTT.
The view won't return you those entities during the running iteration. Instead, they are returned by subsequent iterations.
The same doesn't apply if you iterate raw data (ie if you get the size and a naked pointer through the data member function).

[vblanco20-1]

http://victor.madtriangles.com/code%20experiment/2018/06/11/post-ecs-battle-huge.html I wrote an article about my battle simulation 2.0, this time without unreal engine and on a custom engine.
Im using the external for_each and some other parallel stl like std::sort for it, wich makes the battle scale almost linearly with cores. Most of the systems scale linearly.

I will publish the source code of this once i clean it up a bit. Currently it has some spectacular hacks, such as using tag components to filter the transform components by their hierarchy level, wich lets me calculate the relative transforms for parent-child relations in a cache friendly multithreaded fashion. 4 miliseconds to update the transform matrices of 120.000 objects. Inspired by this http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

[skypjack]

@vblanco20-1 Good job!! It had been a pleasure to collaborate with you, your articles are really interesting indeed.
Two questions: can I add your article to the list at the end of the README? Would you mind to ping me when you publish the code, so as to add it to the same list when ready (and to look at it also)?
It would be great, this is really a good example of use for EnTT.