classes declare the registry they belong to

[jll63]

(Written by Claude Code, on behalf of @jll63.)

Closes #82.

A class can name the registry it belongs to, once, next to itself:

class Animal {
    friend auto boost_openmethod_registry(Animal*) -> zoo_registry;
};

or, equivalently, with a member typedef:

struct Node {
    using boost_openmethod_registry = nodes_registry;
};

The class then has an affinity for that registry, and everything that mentions
it finds it: virtual_ptr, its two deduction guides, final_virtual_ptr, the
smart pointer aliases and their make_*_virtual factories, and any method that
takes the class as a virtual parameter. A method declared without a registry
argument takes the affinity its virtual parameters agree on.

BOOST_OPENMETHOD_CLASSES(Animal, Dog, Cat, zoo_registry);

// no registry argument: speak follows Animal
BOOST_OPENMETHOD(speak, (virtual_<const Animal&>), std::string);

static_assert(std::is_same_v<virtual_ptr<Dog>, virtual_ptr<Dog, zoo_registry>>);

registry_affinity<T> reads it back.

Notes on the shape

Two spellings, typedef first. The function is found by argument-dependent
lookup, which is what lets one declaration cover a hierarchy and lets a class
declare an affinity for a class it does not own. It is also ADL's weaknesses: an
overload outside the class's namespace is silently ignored, a translation unit
that does not include it compiles the same method into another registry, and a
namespace-wide function template outranks an inherited affinity. The member
typedef has none of those - it is ordinary member lookup, so it is inherited,
hidden by a derived class's own, and ambiguous between two bases that disagree -
and it is visible from the point it is declared, which is what a class that
mentions virtual_ptr of itself in its own body needs. Such a class has already
decided to be openmethod-aware; the typedef intrudes no further.

Class*, not Class& as sketched in the issue. It matches the hook
inplace_vptr.hpp already had, so those classes get the behaviour for free;
pointers pass through the ... fallback safely, where a class lvalue is only
conditionally supported; and an overload on Base* ranks below an exact
Derived* one, which is what lets one declaration cover a hierarchy while a
derived class can still override it.

The catch-all returns a sentinel, detail::default_affinity, not a
registry. "Declares nothing" and "declares an affinity for the default registry"
are then distinct: the second constrains a method like any other declaration,
where recovering "no opinion" by comparing with the macro would have made it
yield. registry_affinity maps the sentinel to
BOOST_OPENMETHOD_DEFAULT_REGISTRY and remains a query that always answers a
registry.

No affinity is not an affinity for the default registry. Only a declared one
constrains, so a method may mix a class that declares one with a class that does
not - a first affinity does not cascade errors through a codebase. Two
conflicting affinities are diagnosed, as is a registry named on a method that
contradicts one of its parameters, in any of the four parameter shapes. A
virtual_ptr<Class, R> parameter contributes its class's affinity, never the
R it spells; the two must agree.

A class whose base's overload cannot be used is diagnosed, not defaulted. An
ambiguous or inaccessible base conversion is a substitution failure, so a class
with two differently-hooked bases, a private hooked base, or a repeated
non-virtual hooked base gets a message telling it to declare its own.

The answer is memoized, and asked again where it matters. registry_affinity
is a class template specialization: asked once per class, then remembered. A
class mentioned before it is complete - virtual_ptr<Node> as a member of
Node, or through a forward declaration - is asked before a declaration further
down its body, or a base class, can be seen. Refusing to answer is not an
option: virtual_ptr<Node> next; in a plain linked structure declares no
affinity, needs none, and has worked since #109. So the question is tagged. The
answer that builds types is the one above; check_affinity puts the same
question again where the class must be complete anyway - a virtual parameter, a
class registration - and refuses an answer that has changed. Declaring nothing
stays silent; declaring too late is an error, reported where a wrong registry
would do its damage rather than at the mention, where nothing is wrong yet.

Compatibility

With nothing declared anywhere the catch-all answers for every class, so
registry_affinity<T> is BOOST_OPENMETHOD_DEFAULT_REGISTRY and nothing
changes. Measured rather than argued: for test_virtual_ptr_dispatch.cpp at
-O2 -g0, .text is byte-identical and all 530 defined symbols are unchanged.
No existing spelling changes meaning or stops compiling, including
BOOST_OPENMETHOD(..., R) over an unhooked virtual_<T>.

Deliberately out of scope

• virtual_ keeps its single template parameter. Giving it a Registry would
  cost a mangled-name change for every method<...> mentioning it, nine
  pattern-match edits in core.hpp, and twelve specializations in the any and
  type_erasure headers. Scanning the parameter list reaches the same place.
• use_classes / BOOST_OPENMETHOD_CLASSES still register into the macro
  default unless a registry is listed last. Registering a class that has an
  affinity without naming its registry is a run-time missing_class, not a
  compile error - documented with a warning, and the obvious follow-up. The
  C++26 reflection registrar has the same fallback.
• The any and type_erasure interop headers are untouched.

Tests and docs

Eight tests and eleven compile-fail tests, one per diagnosis. 185/185 pass under
gcc 13.3 Release with examples, and 191/191 under gcc 16 with C++26 reflection
and BUILD_SHARED_LIBS=ON, both with BOOST_OPENMETHOD_WARNINGS_AS_ERRORS=ON;
every compile-fail diagnostic was also matched under clang 18.1. Documentation
introduces "registry affinity" as the term, in registries_and_policies.adoc,
with a new example; mrdocs.yml stops excluding the hook, so it and
registry_affinity now have reference pages.

Since the first review round

Rebased onto current develop. A multi-angle review of the branch found five
ways the affinity was answered wrongly or unchecked, each reproduced on gcc 13,
clang 18 and MSVC, and all five are fixed in the last commit: the memoization
above; an anchor that unwrapped anything with a nested element_type, so a
polymorphic class defining one lost its affinity (it now goes through
virtual_traits); a return type taken verbatim, so -> const zoo_registry was
a distinct registry with its own state and -> int failed far from the
declaration; the sentinel above; and a mismatch check that covered only one of
the four parameter shapes. The virtual_ptr part of that work - a constraint
that demanded a complete class too early - was split out and merged separately
as #109.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RQG6CbE4o2agseE7bDVzHS

[cppalliance-bot]

An automated preview of the documentation is available at https://96.openmethod.prtest3.cppalliance.org/libs/openmethod/doc/html/index.html

If more commits are pushed to the pull request, the docs will rebuild at the same URL.

2026-09-15 01:51:55 UTC

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.25%. Comparing base (d44aa59) to head (ab876ed).
⚠️ Report is 1 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop      #96      +/-   ##
===========================================
- Coverage    93.51%   93.25%   -0.26%     
===========================================
  Files           22       22              
  Lines         1695     1706      +11     
  Branches       504      509       +5     
===========================================
+ Hits          1585     1591       +6     
- Misses          66       71       +5     
  Partials        44       44              

Files with missing lines	Coverage Δ
include/boost/openmethod/core.hpp	91.60% <100.00%> (-1.49%)	⬇️
include/boost/openmethod/inplace_vptr.hpp	100.00% <ø> (ø)
...e/boost/openmethod/interop/boost_intrusive_ptr.hpp	94.44% <ø> (ø)
...nclude/boost/openmethod/interop/std_shared_ptr.hpp	94.73% <ø> (ø)
...nclude/boost/openmethod/interop/std_unique_ptr.hpp	90.00% <ø> (ø)

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 10bdfe5...ab876ed. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.