如何向特定功能添加编译时元数据/行为

Question

My codebase is C++ on NXP ARM M4 with custom C++ RTOS.

There exists a certain function, DWB() aka DangerWillRobinson() , that if called could have unexpected side-effects (which are valid when it's used correctly).

DWB() could be called in a very deeply nested manner as in A()->B()->C()->D()->...->DWB()

I want author of any functions that, directly or indirectly, call DWB() to be aware that DWB() is called and I want to force them to acknowledge that they know DWB() is called.

I know this could be accomplished by parsing the linker's generated call-trees using Python but I'd much prefer this to be a compile-time error thing.

Here's how I'd like this to work:

void A()
{
    B();
}

Author goes to compile:

ERROR: DWB() is called. Please acknowledge.

Author then thinks about side-effects of calling DWB() and finds no issues.

void A()
{
    // some macro-thing ... ?
    B();
}

If possible, I do not want this to be a runtime check. I think in theory, this is possible. If Base is inherited, I would like all possible classes' call-trees to be considered; it's ok if none of them are even instantiated but not ideal.

QUESTION

Is this compile-time metadata/behavior of a function possible?

Answer 1

Is this compile-time metadata/behavior of a function possible?

No, it isn't. There might be some configurable SCA tools available (consider a commercial high level one), but not with plain c-preprocessing or meta-template-programming magic.

---

I want author of any functions that, directly or indirectly, call DWB() to be aware that DWB() is called and I want to force them to acknowledge that they know DWB() is called.

The least intrusive way to do that is to mark the DWB() function [[deprecated]] .

I just suppose you prefer to factor out such error prone function in a midterm roadmap, and replace it with something more stable.

The most quick way in case you are sure what all the conditions of a correct DWB() call are is to apply a bunch of assert() calls at the start of that function.

There might come up complaints from fellow developers, which are trying to use that function incorrectly. Give them best advice as you can in the assertion messages.