KTech::CachingRegistry< T > Class Template Reference

Registry that retrieves world structure pointers by serializable ID. More...

#include <cachingregistry.hpp>

Public Member Functions
auto	operator[] (const ID< T > &id) -> T *
	Retrieve structure using its ID.
auto	Exists (const ID< T > &id) -> bool
	Check if an ID matches a registered structure.

Friends
class	Memory

Detailed Description

template<typename T>
class KTech::CachingRegistry< T >

Registry that retrieves world structure pointers by serializable ID.

From the "How does `CachingRegistry` work?" faq.md entry:

‍KTech::ID is initialized with a UUID value when constructed, meaning, references to world structures (classes that have an ID m_id member) are serializable. All that is left is some kind of a container to store world structure instances or register world structure pointers, so world structures can be retrieved using their IDs.

I chose to register pointers rather than store instances, and KTech::CachingRegistry is implementation. Its purpose is to retrieve a registered world structure pointer, given a corresponding UUID. As its name suggests, it doesn't simply iterate through all registered world structures and retrieves the one that has the matching UUID, but rather, it uses some kind of caching-related optimization.

KTech::ID doesn't only comprise a UUID value: it also has an index (ID::m_i). This member is used by CachingRegistry to cache the last known index in the registry of the associated world structure. When CachingRegistry attempts to retrieve a world structure pointer, it first checks if the UUID of the given ID matches the UUID of the world structure registered at the given cached index. Optimally they match, so it simply returns the pointer from the cached index. If they don't, it iterates down the registry until it finds the matching UUID (i.e. the wanted world structure).

CachingRegistry will update the cached index of any ID it receives, expediting future usages of that ID. The cached index of ID is declared mutable, which is how CachingRegistry can modify it even though it asks for const-references of IDs.

Additionally, considering KTech is designed to work single threaded, keeping a direct pointer to a world structure retrieved from CachingRegistry for the duration of a single function, after validating it (using CachingRegistry::Exists() or checking that the returned pointer is not nullptr), is valid practice, as nothing external should erase the pointed world structure from memory in the meantime.

See also

KTech::ID

Member Function Documentation

Exists()

template<typename T >

auto KTech::CachingRegistry< T >::Exists ( const ID< T > & id ) -> bool

inline

Check if an ID matches a registered structure.

Parameters

[in,out]

id

The structure's ID. Updates its cached index if it's stale.

Returns

true: the structure exists.

false: ther structure doesn't exist.

operator[]()

template<typename T >

auto KTech::CachingRegistry< T >::operator[] ( const ID< T > & id ) -> T*

inline

Retrieve structure using its ID.

Parameters

[in,out]

id

The structure's ID. Updates its cached index if it's stale.

Returns

Pointer to the structure.

nullptr if the structure was not found.

---

The documentation for this class was generated from the following files:

• ktech/ktech.hpp
• ktech/utility/cachingregistry.hpp