I have functions in my company code that have non-void return types but can find themselves with a runtime NEED_CODE exception to be thrown for scenarios we need to address but haven't finished the logic for. An example of an unfinished function below.
int myFutureFeature()
{
NEED_CODE; // A macro set by our company to throw an exception with message
return 0;
}
In these scenarios, we will trigger duplicateBreak conditions in cppcheck if we leave the return statement after the exception, and compile time warnings if we don't (if I remember correctly). I'm thinking of suppressing duplicateBreak, though it has found valid cases before. Is there a modification to the code I can consider to fix this issue of consecutive breaks?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is the scenario I'm truly stuck on which is not as simple as removing the function. Cppcheck has been good in sparking discussions on whether we still have plans to develop functions such as the ones above, but there are cases where I don't have a choice in removing a function.
The following is an example (roughly) found in our code (I've tried to simplify it to illustrate the concern). The macro below serves as a wrapper function for an interface. It selects and calls the appropriate version of a math function (CUDA-based or C++ based).
It's easy to see duplicateBreak being thrown when the prepocessor directive HAVE_CUDA is not defined. It will simply throw a NEED_CODE exception and then give whatever return type was needed by the compiler. The two returns are redundant, but (I think) needed to compile without warnings.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the response. The solution we found was very similar, putting #ifndef CPPCHECK around those macros. It proved to create fewer false positives than commenting out the NEED_CODE exception through macros.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have functions in my company code that have non-void return types but can find themselves with a runtime
NEED_CODE
exception to be thrown for scenarios we need to address but haven't finished the logic for. An example of an unfinished function below.In these scenarios, we will trigger
duplicateBreak
conditions in cppcheck if we leave thereturn
statement after the exception, and compile time warnings if we don't (if I remember correctly). I'm thinking of suppressingduplicateBreak
, though it has found valid cases before. Is there a modification to the code I can consider to fix this issue of consecutive breaks?A More Complex Scenario: Text substitution
Here is the scenario I'm truly stuck on which is not as simple as removing the function. Cppcheck has been good in sparking discussions on whether we still have plans to develop functions such as the ones above, but there are cases where I don't have a choice in removing a function.
The following is an example (roughly) found in our code (I've tried to simplify it to illustrate the concern). The macro below serves as a wrapper function for an interface. It selects and calls the appropriate version of a math function (CUDA-based or C++ based).
It's easy to see
duplicateBreak
being thrown when the prepocessor directiveHAVE_CUDA
is not defined. It will simply throw aNEED_CODE
exception and then give whatever return type was needed by the compiler. The two returns are redundant, but (I think) needed to compile without warnings.You could add a
CPPCHECK
define when checking with cppcheck and then defineNEED_CODE
as:Thanks for the response. The solution we found was very similar, putting
#ifndef CPPCHECK
around those macros. It proved to create fewer false positives than commenting out theNEED_CODE
exception through macros.