boost::openmethod::registry

Methods, classes and policies.

Synopsis

Declared in <boost/openmethod/preamble.hpp>

template<class... Policy>
class registry
    : public /* implementation-defined */

Description

Methods exist in the context of a registry. Any class used as a method or overrider parameter, or in as a method call argument, must be registered with the same registry.

Before calling a method, its registry must be initialized with the initialize function. This is typically done at the beginning of main.

Multiple registries can co‐exist in the same program. They must be initialized individually. Classes referenced by methods in different registries must be registered with each registry.

A registry also contains a set of policies that control how certain operations are performed. For example, the rtti policy provides type information, implements dynamic casting, etc. It can be replaced to interface with custom RTII systems (like LLVM's).

Policies are implemented as Boost.MP11 quoted metafunctions. A policy class must contain a fn<Registry> template that provides a set of static members, specific to the responsibility of the policy. Registries instantiate policies by passing themselves to the nested fn class templates.

There are two reason for this design.

Some policies are "stateful": they contain static data members. Since several registries can co‐exist in the same program, each stateful policy needs its own, separate set of static data members. For example, vptr_vector, a "vptr" policy, contains a static vector of vptrs, which cannot be shared with other registries.

Also, some policies need access to other policies in the same registry. They can be accessed via the Registry template parameter. For example, vptr_vector hashes type_ids before using them as an indexes, if Registry cotains a type_hash policy. It performs out‐of‐bounds checks if Registry contains the runtime_checks policy. If an error is detected, it invokes the error_handler policy if there is one.

A registry is identified by its policy list, not by the class that derives from it. Everything a registry owns is keyed on the registry specialization, which is what registry_type aliases. Two classes built from the same policies, in the same order, are therefore the same registry:

struct animals : registry<policies::std_rtti, policies::vptr_map<>> {};
struct vehicles : registry<policies::std_rtti, policies::vptr_map<>> {};

// the policy lists are identical, so this is one registry, not two
static_assert(std::is_same_v<animals::registry_type, vehicles::registry_type>);

This matters when a second registry exists to isolate a set of methods from another, since it would naturally be given the same policies. Give each one a policy of its own to keep them apart:

// a policy in a category of its own, carrying nothing but a number
struct marker_category {
    using category = marker_category;
};

template<int N>
struct marker final : marker_category {
    template<class Registry>
    struct fn {};
};

struct animals : default_registry::with<marker<1>> {};
struct vehicles : default_registry::with<marker<2>> {};

static_assert(!std::is_same_v<animals::registry_type, vehicles::registry_type>);

Requirements

Policy must contain a category alias to its root base class. The registry may contain at most one policy per category.
Policy must contain a fn<Registry> metafunction.