We have a large C project with warnings as errors enabled. We would like to deprecate some old APIs, and naturally our first thought was to turn to the [[deprecated]] language feature. This however triggers a -Wdeprecated-declarations warning, which is turned into an error and fails the build.

Now, we know we can disable the error for that particular warning via -Wno-error=deprecated-declarations. But still the build log would be full of compiler warnings, making it much harder to spot true compiler errors.

I wonder then if people have better solutions to deal with C deprecations in practice, in real-world large projects?

CodePudding user response：

Well, you can't have your cake and eat it too: If you don't want usage of deprecated functions to throw an error (which can be fine) but neither to see the warnings - why deprecate them in the first place ?

You can suppress single warnings by number (see here for a VC solution: https://stackoverflow.com/a/7159392/20213170), but the correct way is really just getting rid of the deprecated functions calls and update you API.

CodePudding user response：

This is a naive approach, but couldn't you just do something like :

#ifdef WARNING_DEPRECATED_ON
# define ATT_DEPRECATED __attribute__ ((deprecated))
#else
# define ATT_DEPRECATED
#endif 

CodePudding user response：

You can locally have one commit where you deprecate the api, verify that commit doesn't build, then have another commit that removes the uses of the deprecated api.

If you can't push a failing build, at that point you can squash those two local commits into one "remove deprecated api" commit.

But still the build log would be full of compiler warnings, making it much harder to spot true compiler errors.

This isn't completely true. There are a whole bunch of -Wdeprecated-declarations warnings, but any other error fails the build. It's not hard to ctrl-f "error:" in the build log.