Entt: [Feature Request] Better name for default registry + forwarding header

[Kerndog73]

The name of the default registry is entt::registry<>. I think the <> in this name is a bit ugly. The name of the default entity identifier is entt::registry<>::entity_type. I don't like these names. I think the defaults should have short names.

I suggest creating a forwarding header similar to <iosfwd> that forward declares all of the templates in the library. This might improve compilation times because you can just use the forwarding header when you're passing around a reference to the registry or some other EnTT class.

The registry could be named in a similar way to std::string. There will be an entt::basic_registry template and an entt::registry alias for the common case. The forwarding header will declare the registry alias as well as an entity alias for the default entity type.

// enttfwd.hpp

#include <cstdint>

template <typename>
class basic_registry;

using entity = uint32_t;
using registry = basic_registry<entity>;

// everything else...

The registry header should include the forwarding header to make these aliases available when the registry header is included.

// entity/registry.hpp

#include "../enttfwd.hpp"

template <typename Entity>
class basic_registry {
// ...
};

If we run #include <entt/entity/registry.hpp> through the preprocessor only, we end up with a 1.3MB file. Forward declarations might speed up compile times in certain situations.

The new name for the default registry is entt::registry and the default entity is entt::entity. In the rare case that uint32_t is insufficient, there's nothing stopping the user from making their own type alias for entt::basic_registry<uint64_t> or something.

[skypjack]

Are there other types for which this approach would be beneficial?
This way I can make the work once and forever instead of a piece at a time.

[Kerndog73]

@skypjack prototype. Maybe actor as well

[skypjack]

Probably it's worth doing this for each subdir. I mean, something like entity_fwd.hpp within src/entt/entity, signal_fwd.hpp within src/entt/signal and so on. The other way around is a companion entt_fwd.hpp for entt.hpp that contains all the possible declarations.
Not sure about what could be better in real use cases tbh.

[Kerndog73]

Yeah, that makes sense. How often do you #include <entt/entt.hpp>? I certainly never have.

[ArnCarveris]

@skypjack @Kerndog73 why not #include <entt/fwd.hpp>?

[skypjack]

@Kerndog73 @ArnCarveris I didn't understand which one of the two approaches you like more!! :smile:
Single forward header or multiple forward headers per sbdir?

[ArnCarveris]

@skypjack Well I think better be put it in one file, it may be better for compilation time, but not sure need test @Kerndog73

[Kerndog73]

How about a header for each subdirectory AND and header for the whole library? I like @ArnCarveris's name for the header: fwd.hpp

[skypjack]

It makes sense: if you cannot decide, proceed on both the sides. :+1: :joy:

[skypjack]

I would add to the list the snapshot class probably. Moreover, why not:

template<typename Entity, typename... Component>
struct basic_view { ... }

template<typename... Component>
using view = basic_view<entity_type, Component...>;

This way views (and groups) will be identified as view<A, B, C>, without the annoying initial Entity .

[Kerndog73]

Maybe make things more comfortable for the 0.001% of people using 64 bit IDs.

// config.hpp

#ifndef ENTT_DEFAULT_ENTITY
#define ENTT_DEFAULT_ENTITY uint32_t
#endif

// fwd.hpp

using entity = ENTT_DEFAULT_ENTITY;

The default entity is uint32_t by default.

Maybe this is silly?

[skypjack]

It would make cleaner the code also for those that use uint 64 actually.

[skypjack]

Almost done. I was trying to figure out if it's worth it to add a forward declaration for a sparse set.
Tbh I don't think so, mainly because 1) the sparse set is a kind of internal data structure rarely used by users and 2) the forward declaration would be something like this:

template <typename...>
class basic_sparse_set;

template<typename... Types>
using sparse_set = basic_sparse_set<entity, Types...>;

It means that the base implementation has still to be defined as entt::sparse_set<>, while the derived one would be entt::sparse_set<my_type>.

---

As a side note, it seems to me that nothing but the classes within src/entity can be forward declared.
For all the other parts of the library I don't see any benefit and in most cases any way to forward declare types (eg sigh or delegate require a function type, there is nothing to forward declare in this case).

[skypjack]

Classes for which a forward declaration seems to make sense:

• entity
• registry
• actor
• prototype
• snapshot
• snapshot_loader
• continuous_loader
• view
• group

I'm pushing it on experimental branch. Feedback are highly appreciated.

[Kerndog73]

Looks good! 👍 I didn't quite get your reason for excluding signals and the rest of the library from a forwarding header. Could you elaborate?

I don't really mind. I'm just curious.

[skypjack]

@Kerndog73 the main reason is that I was tired and I wrote a silly thing. :smile:

[Kerndog73]

@skypjack Makes sense

[skypjack]

What about the sparse set instead? I don't think a forwarding header would help much here and the syntax will remain ugly anyway.

[Kerndog73]

sparse_set is an implementation detail. I think you made the right decision.

[skypjack]

There should be everything. Did I forget something at a quick glance?

[Kerndog73]

You didn’t forward declare everything but that doesn’t really matter. You covered the most used parts of the library so I’m happy with the changes. The changes to the registry are the main thing.

[skypjack]

I left out some things that doesn't make much sense to forward declare from my point of view.
As an example, emitter: it's a CRTP class, forward declare it is pointless, you won't use the forward declaration in any case.
I left some other classes out for similar reasons.

[Kerndog73]

Yeah, makes sense. As long as the registry is renamed and forward declared, I’m happy.

[skypjack]

Also, guess what? We can still add classes and fwd.hpp files in future if we find we forgot something important!! Let's merge it, you're waiting for it since long time ago!! :smile:

[Kerndog73]

I’ve been waiting for this all my life!