- Generated on Thu Dec 4 2025 for mimic++ by
1.13.2
|
mimic++ v9.2.1
|
Contains documentation for the possible configuration options.
Contains documentation for the possible configuration options.
mimic++ offers various configuration options, which are listed below. In general, these options can be enabled by defining a macro with that specified name, before any mimic++ header is included. If mimic++ is integrated as cmake-target, it also offers appropriate cmake-options with the same name, which can be set during cmake configuration. If an option is enabled, mimic++ defines the relevant macro by itself.
Name: MIMICPP_CONFIG_ONLY_PREFIXED_MACROS
By default, mimic++ defines several shorthand macros for their longer counterparts, to make it less verbose (e.g SCOPED_EXP is shorthand for MIMICPP_SCOPED_EXPECTATION). Even if very unlikely, this may lead to name clashes with other dependencies. Because of that, the option MIMICPP_CONFIG_ONLY_PREFIXED_MACROS is offered, which then disables all shorthand macros.
fmt as formatting backendName: MIMICPP_CONFIG_USE_FMT
As of c++20, the format library is officially part of the std. Unfortunately some compilers — while supporting most C++20 features — do not yet support the formatting library. In such cases, users can enable this option to use fmt as a fallback.
Whatever the reason to use fmt might be, chances are good that the library is already present. mimic++ attempts to detect it when linked as CMake target, before pulling it from GitHub. To reuse an existing fmt package, ensure it can be found via find_package(fmt).
If C++20 modules are supported, you can also control how fmt is included via the MIMICPP_CONFIG_IMPORT_FMT option (default: ON). When set to ON, import fmt; will be used. Otherwise, it will fall back to a traditional #include directive.
Name: MIMICPP_CONFIG_EXPERIMENTAL_CATCH2_MATCHER_INTEGRATION
If enabled, all matchers from the Catch::Matcher namespaces can be directly used everywhere, where mimic++-matchers are suitable.
Unfortunatly catch2 matchers are desgined to be used in-place. Every combination you do, like negation via operator ! or operator &&, just takes a const-reference to the source-matcher.
mimic++ needs to store the matcher inside the expectation. These requirements are not playing well together. Nevertheless catch2 offers some nice matcher definitions, which could be very helpfull for testing. But as already said, they are dangerous, thus I decided to make them opt-in as experimental features.
Name: MIMICPP_CONFIG_EXPERIMENTAL_UNICODE_STR_MATCHER
If enabled, all string-matchers get full unicode support. This is relevant, when comparing case-insensitively. It's not required for the base-version of string-matchers.
This will require the rather light-weight library uni-algo, which can be found on github.
mimic++ first tries to find the dependency via find_package, but will fetch it from github if not available.
I recently switched from cpp-unicodelib, which I didn't like very much for several reasons. uni-algo seems more mature, but I would like to get some feedback, before I'll declare this as a stable feature.
Name: MIMICPP_CONFIG_EXPERIMENTAL_STACKTRACE
When enabled, mimic++ uses stacktrace information to provide more helpful diagnostics. Users can choose between the C++23 std::stacktrace (c++23), the third-party cpptrace (cpptrace) or boost (boost), or a custom stacktrace backend (custom).
In cases where mimic++ is not configured via cmake, users can manually define the following macros (set them to 1) before the inclusion of any mimic++ header.
MIMICPP_CONFIG_EXPERIMENTAL_USE_CXX23_STACKTRACEMIMICPP_CONFIG_EXPERIMENTAL_USE_CPPTRACEMIMICPP_CONFIG_EXPERIMENTAL_USE_BOOST_STACKTRACEMIMICPP_CONFIG_EXPERIMENTAL_USE_CUSTOM_STACKTRACEThe stacktrace integration has recently been reworked. Stacktraces are now collected only when a violation is detected (or settings::report_success is enabled). Previously, they were gathered on every mock call, which introduced significant overhead. With this change, the implementation is close to its intended design and may become stable soon.
Name: MIMICPP_CONFIG_EXPERIMENTAL_PRETTY_TYPES
When enabled, mimic++ enhances type printing to closely match their actual representation in code, making error messages more readable and informative.
However, this feature can introduce additional overhead, especially with heavily templated types. Without it, most types will be printed using typeid(T).name(), or, if mimic++ is given a stringified type-name, it will output that string as-is. This usually provides a rough indication of the type, but often includes extra noise.
The complexity lies in post-processing type strings into a uniform and human-readable format. Since compilers produce inconsistent and platform-dependent type names, mimic++ must handle a wide range of patterns, quirks, and edge cases. While great effort has been made to make this reliable, unexpected cases may still exist in certain environments.
Name: MIMICPP_CONFIG_EXPERIMENTAL_ENABLE_CXX20_MODULES__UNPORTABLE__
C++20 modules have come a long way and are finally appearing on the horizon. Unfortunately, they still require a very up-to-date toolchain (CMake, compiler, etc.), which is often not available by default. Even then, there's a significant chance of encountering compiler bugs that are difficult or impossible to work around. Because of this, users must explicitly opt-in to this feature.
3.28 and later).When enabled, this defines the CMake target mimicpp::module and makes mimicpp::mimicpp an alias for it.
mimicpp::header-only.In addition, this option signals that all (optional) dependencies should be consumed as modules when they provide one.
1.13.2