From 88c27ffaf22b41cfb35400c86b38078e2f7b494b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Martin=20Ho=C5=99e=C5=88ovsk=C3=BD?= Date: Mon, 16 Aug 2021 16:20:32 +0200 Subject: [PATCH] Mention CATCH_MOVE and CATCH_FORWARD in contributing docs --- docs/contributing.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/docs/contributing.md b/docs/contributing.md index 9a85f76a..dc6bb537 100644 --- a/docs/contributing.md +++ b/docs/contributing.md @@ -210,7 +210,7 @@ are problematic and are not always caught by our CI infrastructure. #### Naked exceptions and exceptions-related function If you are throwing an exception, it should be done via `CATCH_ERROR` -or `CATCH_RUNTIME_ERROR` in `catch_enforce.h`. These macros will handle +or `CATCH_RUNTIME_ERROR` in `internal/catch_enforce.hpp`. These macros will handle the differences between compilation with or without exceptions for you. However, some platforms (IAR) also have problems with exceptions-related functions, such as `std::current_exceptions`. We do not have IAR in our @@ -219,6 +219,18 @@ However, if you do, they should be kept behind a `CATCH_CONFIG_DISABLE_EXCEPTIONS` macro. +#### Avoid `std::move` and `std::forward` + +`std::move` and `std::forward` provide nice semantic name for a specific +`static_cast`. However, being function templates they have surprisingly +high cost during compilation, and can also have a negative performance +impact for low-optimization builds. + +You should be using `CATCH_MOVE` and `CATCH_FORWARD` macros from +`internal/catch_move_and_forward.hpp` instead. They expand into the proper +`static_cast`, and avoid the overhead of `std::move` and `std::forward`. + + #### Unqualified usage of functions from C's stdlib If you are using a function from C's stdlib, please include the header