5

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?

user1011113
  • 1,114
  • 8
  • 27
  • 4
    What do you want `[[deprecated]]` to do? – n. m. could be an AI Oct 13 '22 at 07:37
  • 2
    Typically a good maintainer of a database will take the deprecated warnings seriously and fix them up just like they're real errors. So they _should_ actually be errors or at least warnings cluttering his screen. What else do you want? Seems like you want to warn the devs but at the same time not bother them... – glades Oct 13 '22 at 07:38
  • 4
    How would anyone *know* they are using a deprecated function somewhere without ever seeing a diagnostic pointing at that place? – StoryTeller - Unslander Monica Oct 13 '22 at 07:40
  • It might be easier and more pragmatic to just inventory what you want to remove and create work items in your bug database (or product backlog) for each API. Then enable the deprecation warnings after this work is done. – selbie Oct 13 '22 at 07:49
  • 2
    The best practice against deprecated code is updating it. In large projects you will have equally many developers who can go and fix the underlying problem instead of battling with the warning priorities. – Peter Krebs Oct 13 '22 at 07:49
  • 1
    Real problem is that your code is using deprecated API (only case when warning is triggered). Your code should not use deprecated API after all should not be used anymore. The only place where it could be is used are tests (to maintain compatibility), but there you can disable warning locally `#pragma push ... pop` – Marek R Oct 13 '22 at 07:53
  • I would either accept that the log would be filled with deprecated warnings, or write a log filter. But people make a good point, why create the warning if you're then going to hide it away? – Galik Oct 13 '22 at 08:30
  • I suppose what I want to achieve is: when developers build their little piece of code, they should get the warning showing up to inform them that they need to fix their code. When code is built in CI, we don't want these warnings to show up - instead only true compiler errors should appear. Perhaps I can write a log filter as Galik says. I'd like to avoid divergence in compiler flags between local build and CI build. – user1011113 Oct 13 '22 at 09:24

3 Answers3

3

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.

nick
  • 541
  • 1
  • 9
  • Hey guys, i'm not sure what the SO ettiquette here is: I know for external links, i'm supposed to at least give a summary of the code used. For internal links to other SO answer you do not, right ? – nick Oct 13 '22 at 08:10
3

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
carce-bo
  • 480
  • 2
  • 10
  • 1
    This seems like a very practical approach. You could then have a special `make` target which triggers all the deprecated errors when you want to start fixing them. – Galik Oct 13 '22 at 08:34
0

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.

Caleth
  • 52,200
  • 2
  • 44
  • 75