Separate macro definitions from proxy.h? (C++20 named modules support)

[SidneyCogdill]

C++ module support is available starting with Proxy 4

#293

---

Latest version of clangd (21 from development branch) seems to have good-enough C++20 modules support now (no more random crashes; parses very fast; type inference and go-to-definition works) and I'm starting to adapt it and it's showing observable compilation time speedup. Most libraries that use header files can be wrapped with their interfaces manually exported in a standard module:

// std_.cpp
module;

#include <array>

export module std_;

export namespace std {
using std::array;
}

// main.cpp
import std_;

int main() {
    std::array<int, 4> a;
}

(yes, stdlib included, although fiddling with std namespace is technically undefined behavior)

However, modules can't export preprocessor macros, therefore the PRO_DEF_MEM_DISPATCH and friends aren't usable when proxy is contained in a separate module, unless proxy.h is included.

I see that with the latest commit, proxy changes from single-header-only to header-only.

It would be nice if the macro definitions are defined in a separate file. The proxy.h would still include the macro definitions, and a separate proxy_macros.h would be also accessible (which is included by proxy.h), similar to Vulkan-Hpp with the <vulkan/vulkan_hpp_macros.hpp>. This would be enough for me to manually adapt proxy with module support.

[SidneyCogdill]

I think the include hierarchy would be somehow along the line of this:

• details/proxy_impl.h contains all the facades and interfaces.
• proxy_macros.h defines only the macros without including the details/proxy_impl.h.
• the final proxy.h includes both details/proxy_impl.h and proxy_macros.h.

import proxy; followed by #include <proxy/proxy_macros.h> (assuming I manually made a proxy module) would work in this case.

[mingxwa]

Hi @SidneyCogdill, thank you for the feedback! Enabling proxy to work with modules, as discussed in #126 last year, seems like a valuable direction. Splitting macros into a separate header file is a good idea but might not suffice for seamless module integration. Definitions like type aliases and concepts, for example, cannot be exported separately without altering implementation details in proxy.h. In the longer term, I believe the library should offer a self-contained module interface, similar to fmt. I will explore further in this direction and spend some time to play with Clang 21. Please let me know if there is any further consideration.

[SidneyCogdill]

Macros are exported in <proxy/proxy_macros.h>.

clangd seems to have another bug where the accessors must be either exported, or be defined within extern "C++" blocks, otherwise auto completions don't work. Check the tests/cpp20_modules.

[SidneyCogdill]

BTW Extracting from docs and building them is nice. Rust has doctests and it's nice to see the same in C++. I think I'm going to steal that extract_example_code_from_docs.py.

[SidneyCogdill]

I think the better way to handle the proxy / proxy_interface split is to refactor the macros so that it no longer depends on non-public implementation details. But I don't know how to refactor it. Macros are hard.

[mingxwa]

Amazing work! I think it's fine to put the 2 facilities in the details namespace into the main proxy module for now.

[SidneyCogdill]

Never thought the changes would be this big. Originally I just wanted to split the macros. But then my mind keeps going "Now that X is complete, might as well also do Y as it's trivial with X already done" and so the small steps stacked up.

I've always thought "C++ toolchains don't have doc tests builtin so maybe just don't do it, use unit test frameworks instead" until seeing the creativity in proxy. So thanks for your doc test Python script which actually inspired me to update it with the more general solution.

[SidneyCogdill]

https://github.com/microsoft/proxy/actions/runs/14962709999/job/42027708969?pr=293

What do we do with the failing CIs? Apparently older versions of GCC (and Clang?) don't have modules support. Neither does nvc++ or AppleClang. But I want to keep the docs example.

Latest releases of MSVC, Clang and GCC all passed the CI.