You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The game body which is created by libgkit is base on unit system. So, I have some idea and design goals about unit system.
The child units' lifetime should be managed by its parent unit, and an application should have a root unit to manage the game running.
The whole unit tree must be lifetime safe. We must to avoid lifetime problem such as dangling reference in grammer level.
We should provide STL-like methods for user, which means to decrease the learning cost for beginner and be compatible with STL algorithms and methods.
In my opinion, child unit can always write and read its parent unit safely, but the parent unit can't visit their child safely(such as out of code scope and free code problem)
In current code, there are some implementation measures
I delete the copy constructure function. Because it will make the parent-child relationship mess. Not only that, but also can avoid user store the unit object in their code which may cause out-of-scope problem.
I provide method with_child(index, func, args...) to visit child unit safely.
And I always use unit reference as the return value of unit function.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
The game body which is created by
libgkitis base on unit system. So, I have some idea and design goals about unit system.In current code, there are some implementation measures
with_child(index, func, args...)to visit child unit safely.All reactions