# Easier integration with C++ clients that benefit from "noexcept" **URL:** \ **Category:** Kernel\ **Tags:** feature-request\ **Created:** [October 17, 2024, 3:44pm UTC](https://forums.freertos.org/t/easier-integration-with-c-clients-that-benefit-from-noexcept/21650 "2024-10-17T15:44:27Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![dc42](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/dc42/32/487_2.png) [@dc42](https://forums.freertos.org/u/dc42)\ **Post date:** [October 17, 2024, 3:44pm UTC](https://forums.freertos.org/t/easier-integration-with-c-clients-that-benefit-from-noexcept/21650/1 "2024-10-17T15:44:27Z")
We use FreeRTOS exclusively from C++. One of our mission-critical embedded applications uses C++ exceptions, so we have to consider both the correctness of exception management and the overheads of calling methods that don’t throw C++ exceptions but are not declared ‘noexcept’. Specifically: 1. If a C++ “noexcept” method calls a function that throws an exception, this will result in termination of the program, which must be avoided. We have an in-house static analysis tool that traces which exceptions each function or constructor might throw, and warns us when a noexcept method might throw. Unfortunately, C methods such as the entry points of FreeRTOS have to be treated as potentially throwing exceptions (because a few C functions can do so), which is problematic even though FreeRTOS never throws C++ exceptions. 2. If a C++ noexcept function calls a potentially-throwing function, then gcc for ARM creates a small exception table for that function. These tables take up flash memory space, which is in short supply in one of our applications on some target MCUs. Therefore we need to ensure that all non-throwing functions called by our application are declared ‘noexcept’ so that this table is not generated. We can’t do this for FreeRTOS functions that we call unless we add ‘noexcept’ specifiers to all the .h files provided by FreeRTOS that declare functions we call. We would much rather use the FreeRTOS header files as published instead of modified versions. My request is that in the header files in the FreeRTOS ‘include’ folder that describe public FreeRTOS entry points be annotated using a macro (for example NOEXCEPT) after the parameter list of each function. This macro could have the following default definition in FreeRTOS.h after the line in which FreeRTOSConfig.h is included: ```auto #ifndef NOEXCEPT # ifdef __cplusplus # define NOEXCEPT noexcept # else # define NOEXCEPT # endif #endif ``` This will ensure that NOEXCEPT is ignored when compiling in C mode, but defaults to expanding to noexcept when a client is compiled with a C++ compiler. ---
**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\ **Post date:** [October 17, 2024, 6:49pm UTC](https://forums.freertos.org/t/easier-integration-with-c-clients-that-benefit-from-noexcept/21650/2 "2024-10-17T18:49:27Z")
Sounds good to me. I have been able to avoid exceptions myself, but I can see the problem. One suggestion, the macro name NOEXCEPT is likely not good, as might interact with other uses of the macro by that name, perhaps FREERTOS\_NOEXCEPT or taskNOEXCEPT might be more inline with the projects naming convention. ---
**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\ **Post date:** [October 18, 2024, 6:09am UTC](https://forums.freertos.org/t/easier-integration-with-c-clients-that-benefit-from-noexcept/21650/3 "2024-10-18T06:09:04Z")
All of the FreeRTOS API functions are already annotated with `PRIVILEGED_FUNCTION` which currently gets defined to nothing on non-MPU ports. What do you think about the following - 1. Change the name `PRIVILEGED_FUNCTION` to something more generic like `FUNCTION_ANNOTATOR`. 2. Guard [these definitions](https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/include/mpu_wrappers.h#L284) with `#ifndef`. 3. You should then be able to the define `FUNCTION_ANNOTATOR` in FreeRTOSConfig.h: - If you use non-MPU port: ```auto #define FUNCTION_ANNOTATOR noexcept ``` - If you use MPU port: ```auto #define FUNCTION_ANNOTATOR noexcept __attribute__ ( ( section( "privileged_functions" ) ) ) ``` Would this address your problem? ---
**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\ **Post date:** [October 18, 2024, 1:22pm UTC](https://forums.freertos.org/t/easier-integration-with-c-clients-that-benefit-from-noexcept/21650/4 "2024-10-18T13:22:02Z")
the noexcept would need to be conditioned on the header being compiled in C++ mode, just like the extern “C” statement, or it will break for the C compilation. ---
**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\ **Post date:** [October 21, 2024, 4:45am UTC](https://forums.freertos.org/t/easier-integration-with-c-clients-that-benefit-from-noexcept/21650/5 "2024-10-21T04:45:44Z")
@richard-damon Assuming that we are talking about my proposal above, `noexcept` is added by the application in `FreeRTOSConfig.h`. So the application writer is free to guard them in whatever way they want. ---
**Author:** ![cookpate](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/cookpate/32/2962_2.png) [@cookpate](https://forums.freertos.org/u/cookpate)\ **Post date:** [October 21, 2024, 5:38am UTC](https://forums.freertos.org/t/easier-integration-with-c-clients-that-benefit-from-noexcept/21650/6 "2024-10-21T05:38:59Z")
That is, assuming there is a need to add a trailing part of a function declaration to a FreeRTOS function. `noexcept` is standard C++, so one would expect a config item such as ```auto #define configUSE_NOEXCEPT 0 ``` and later on ```auto #ifdef __cplusplus # if ( configUSE_NOEXCEPT == 1 ) # define FREERTOS_NOEXCEPT noexcept # endif #endif ``` Regardless of how this is declared, this config item needs to be guarded by the cplusplus ifdef to prevent C compiler errors. ---
**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\ **Post date:** [October 21, 2024, 2:17pm UTC](https://forums.freertos.org/t/easier-integration-with-c-clients-that-benefit-from-noexcept/21650/7 "2024-10-21T14:17:54Z")
> [@aggarg](#): > > @richard-damon Assuming that we are talking about my proposal above, `noexcept` is added by the application in `FreeRTOSConfig.h`. So the application writer is free to guard them in whatever way they want. My point is that currently PRIVILEDGED\_FUNCTION isn’t supposed to be a user altered macro, and there is no reason to not add the noexcept decorator when compiling the headers in C++ mode. As far as I know, it only has negative effects if added to the declaration of a function implemented in C++, but user functions do not have that attribute applied to them so the change won’t affect them. This means that it would make sense to change the definition in mpu\_wrappers.h to do that. It might also make sense to make it conditional so that other attributes could be added if desired, but it seems noexcept could be made standard. ---
**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\ **Post date:** [October 22, 2024, 11:33am UTC](https://forums.freertos.org/t/easier-integration-with-c-clients-that-benefit-from-noexcept/21650/8 "2024-10-22T11:33:25Z")
> [@richard-damon](#): > > there is no reason to not add the noexcept decorator The reason I am less inclined to do that is because it may give an impression that we test in C++ environment with exceptions/no-exceptions which we do not. As you mentioned, the ability to override the decorator still provides people to add any attributes they want. ---
**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\ **Post date:** [October 22, 2024, 1:11pm UTC](https://forums.freertos.org/t/easier-integration-with-c-clients-that-benefit-from-noexcept/21650/9 "2024-10-22T13:11:18Z")
I guess existence of code indicating testing is a reasonable reason. ---
**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\ **Post date:** [October 22, 2024, 3:19pm UTC](https://forums.freertos.org/t/easier-integration-with-c-clients-that-benefit-from-noexcept/21650/10 "2024-10-22T15:19:21Z")
@dc42 Does my suggestion above address your usecase? ---
**Author:** ![dc42](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/dc42/32/487_2.png) [@dc42](https://forums.freertos.org/u/dc42)\ **Post date:** [October 22, 2024, 7:25pm UTC](https://forums.freertos.org/t/easier-integration-with-c-clients-that-benefit-from-noexcept/21650/11 "2024-10-22T19:25:03Z")
@aggarg yes it does address my use case. However, I would hesitate to overload the PRIVILEGED\_FUNCTION macro in this way because it assumes that all FreeRTOS entry points will be privileged functions, both now and in future. I would prefer a separate macro such as FREERTOS\_NOEXCEPT. ---
**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\ **Post date:** [October 23, 2024, 5:16am UTC](https://forums.freertos.org/t/easier-integration-with-c-clients-that-benefit-from-noexcept/21650/12 "2024-10-23T05:16:37Z")
> [@dc42](#): > > @aggarg yes it does address my use case. Thank you! > [@dc42](#): > > However, I would hesitate to overload the PRIVILEGED\_FUNCTION macro in this way because it assumes that all FreeRTOS entry points will be privileged functions, both now and in future. I would prefer a separate macro such as FREERTOS\_NOEXCEPT. Agree and that is why I suggested to use a more generic name like FUNCTION\_ANNOTATOR. ---
**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\ **Post date:** [October 23, 2024, 1:45pm UTC](https://forums.freertos.org/t/easier-integration-with-c-clients-that-benefit-from-noexcept/21650/13 "2024-10-23T13:45:35Z")
> [@aggarg](#): > > Agree and that is why I suggested to use a more generic name like FUNCTION\_ANNOTATOR. I think his concern is that the method assumes that ALL FreeRTOS functions are to be run as “Privileged”, but since that doesn’t mean actually running in privileged mode, just being allowed to switch to that mode, that is likely a fairly safe assumption. ---
**Author:** ![archigup](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/archigup/32/1418_2.png) [@archigup](https://forums.freertos.org/u/archigup)\ **Post date:** [October 25, 2024, 11:21pm UTC](https://forums.freertos.org/t/easier-integration-with-c-clients-that-benefit-from-noexcept/21650/14 "2024-10-25T23:21:17Z")
A single macro for function annotations may be problematic when setting multiple annotations. Also, we would need to be sure our functions can’t throw exceptions by calling a user callback or such. ---
**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\ **Post date:** [October 26, 2024, 4:19pm UTC](https://forums.freertos.org/t/easier-integration-with-c-clients-that-benefit-from-noexcept/21650/15 "2024-10-26T16:19:48Z")
Except for vPortMalloc, I can’t think of any API functions that call user callbacks. And, since vPortMalloc can be called from situations where there is no enclosing C++ context, the vApplicationMallocHook should not be defined to be able to throw exceptions. The other case to think of are the trace macros, but again, they are used in contexts that throwing an exception would not be defined, it should be safe to define them as not being allowed to throw exceptions.