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_CODEexception 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
duplicateBreakconditions in cppcheck if we leave thereturnstatement 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
duplicateBreakbeing thrown when the prepocessor directiveHAVE_CUDAis not defined. It will simply throw aNEED_CODEexception 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
CPPCHECKdefine when checking with cppcheck and then defineNEED_CODEas:Thanks for the response. The solution we found was very similar, putting
#ifndef CPPCHECKaround those macros. It proved to create fewer false positives than commenting out theNEED_CODEexception through macros.