boost::openmethod::registry :: Boost.OpenMethod

# boost::openmethod::registry

Methods, classes and policies.

## Synopsis

Declared in `<boost/openmethod/preamble.hpp>`

    template<class... Policy>
    class registry;

## 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.

## 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.

## Types

Name | Description
`registry_type` | The type of this registry.
`policy_list` | List of policies selected in a registry.
`policy` | Find a policy by category.
`with` | Add or replace policies.
`without` | Remove policies.
`rtti` | The registry's rtti policy.
`vptr` | The registry's vptr policy if it contains one, or `void`.
`error_handler` | The registry's error_handler policy if it contains one, or `void`.
`output` | The registry's output policy if it contains one, or `void`.

## Static Member Functions

Name | Description
`require_initialized` | Check that the registry is initialized.

## Static Data Members

Name | Description
`static_vptr` | A pointer to the virtual table for a registered class.
`has_vptr` | `true` if the registry has a vptr policy.
`has_error_handler` | `true` if the registry has an error_handler policy.
`has_output` | `true` if the registry has an output policy.
`has_deferred_static_rtti` | `true` if the registry has a deferred_static_rtti policy.
`has_runtime_checks` | `true` if the registry has a runtime_checks policy.
`has_indirect_vptr` | `true` if the registry has an indirect_vptr policy.

## Derived Classes

Name | Description
--- | ---
`default_registry` | Default registry.

## Template Parameters

Name | Description
--- | ---
Policy | The policies used in the registry.

## See Also

`policies`

Created with MrDocs