5

I am trying to write a macro to use suppress unused variable warnings when the user wants them (e.g. in derived classes when you have not implemented the whole class yet). I know that I can remove the variable name... but to make it clear I would prefer a macro).

So far I have this:

#ifdef WIN32
    #define UNUSED(x) x
#else
    #define x __attribute__((unused))
#endif

Used like:

void test_fn(int UNUSED(test_var)) {...}

I saw this post: suppressing-is-never-used-and-is-never-assigned-to-warnings-in-c-sharp, but it gave me a result that I can't really use (multiline #pragmas).

So my question is, is there a MSVS equivalent of the __attribute__((unused))? - i.e. on the same line?

Note: this question does not answer how to do what I am asking: how-do-i-best-silence-a-warning-about-unused-variables since it does not cover how to use it within the function prototype in a way that works with both MSVS and gcc.

code_fodder
  • 15,263
  • 17
  • 90
  • 167
  • 3
    If it is not covered in [How do I best silence a warning about unused variables?](https://stackoverflow.com/q/1486904/1708801) then it should be added there. – Shafik Yaghmour Aug 28 '18 at 12:55
  • Possible duplicate of [How do I best silence a warning about unused variables?](https://stackoverflow.com/questions/1486904/how-do-i-best-silence-a-warning-about-unused-variables) – Aconcagua Aug 28 '18 at 12:58
  • 3
    If you get the warning because you haven't implemented the whole class yet, I would happily leave the warning ON, not risking to forget to do it later on. – roalz Aug 28 '18 at 12:59
  • @ShafikYaghmour I would add the answer there...if I knew it :) – code_fodder Aug 28 '18 at 13:18
  • @Aconcagua no, not a dup here because those answers do not meet my requirement. Note: I am using UNUSED(x) within the function parameters not in the code, so void casting etc... does not work. I have read that post too :) – code_fodder Aug 28 '18 at 13:19
  • Simply don't name the parameter in the first place: `void test_fn(int) {...}`. – Sam Varshavchik Aug 28 '18 at 13:20
  • @PostSelf I did mention that "I know that I can remove the variable name..." but for the reason given I didn't want to do that. However.... that does give me the idea to just do `#define UNUSED(x) ` to for WIN32 to "delete" the variable... – code_fodder Aug 28 '18 at 13:21
  • @SamVarshavchik same comment as just above.. – code_fodder Aug 28 '18 at 13:21

2 Answers2

4

If a variable or function-argument is potentially unused, gcc's __attribute__((unused)) is designed to suppress any warning about it.

Now, if you want something portable, there are multiple choices:

  1. If you don't use it,
    1. and it's a function-argument, just don't name it.
    2. otherwise, simply don't create it.
  2. If it might be used under some circumstances, simply use it once definitely by casting to void:

    (void)potentially_unused;
    

    Yes, the second option is not in the prototype, but one has to make allowances.

  3. Upgrade to C++17 and use [[maybe_unused]].

Deduplicator
  • 44,692
  • 7
  • 66
  • 118
  • MSVS 2019 v16.6 and higher supports `[[maybe_unused]]`, (Available with [/std:c++20](https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-170) and later): https://learn.microsoft.com/en-us/cpp/cpp/attributes?view=msvc-170 – paulsm4 Apr 20 '22 at 05:55
3

If your usage is only

void test_fn(int UNUSED(test_var)) {...}

I know that I can remove the variable name... but to make it clear I would prefer a macro).

So remove variable name through MACRO:

You can go with

#define UNUSED(x) /*Empty*/
Jarod42
  • 203,559
  • 14
  • 181
  • 302
  • Yeah, this is the one I want!... infact that probably works for both gcc and MSVS :) Thanks. – code_fodder Aug 28 '18 at 13:24
  • Just thought... added benefit is that when you want to use the variable you have to remove the UNUSED(..) part otherwise you would get a compile error ... nice ... : ) – code_fodder Aug 28 '18 at 13:25
  • @code_fodder Ultimately though, are you sure you *want* to remove the warning? If your scenario is that the warning is caused because you have functions you haven't come around to implementing yet, the warning will helpfully remind you of that. – François Andrieux Aug 28 '18 at 13:26
  • @FrançoisAndrieux in this case... yes, we want to use `-Werror` to enforce lazy b*ggers who don't want to sort out their errors (and by that I mean warnings) : )) – code_fodder Aug 28 '18 at 13:28
  • 1
    My question is would it have been better to post this in the [question I linked above](https://stackoverflow.com/questions/52058457/visual-studio-equivelent-of-gcc-attribute-unused-in-c11-or-lower?noredirect=1#comment91067081_52058457) and close this as a duplicate? – Shafik Yaghmour Aug 28 '18 at 15:41
  • I don't see why one would want to rely on compiler extensions if there's a standard way - what is here used for windows would work with GCC as well, so I'd have one and the same macro for both/all compilers... – Aconcagua Aug 28 '18 at 20:32
  • @ShafikYaghmour As the OP, I don't feel its right for me to post the answer. But if you update your answer with these details then I will happily mark this as a dup... – code_fodder Aug 29 '18 at 06:16
  • @Aconcagua I do prefer a standard way, but unless we are using c++17 there is not one by design. I just never though of defining a macro as blank like Jarod suggested. Now that he has I have infact used this solution for both.... : ) – code_fodder Aug 29 '18 at 06:17
  • 1
    @code_fodder *"there is not one by design"* - just to be precise: Not naming the parameters *is* standard and was even before C++11(!) - if you do so directly or use a macro to get the effect is irrelevant... – Aconcagua Aug 29 '18 at 08:32
  • 1
    The nice thing about this solution is that it works even in C, but for declarations only (in definitions, parameters *must* be named). So if you happen to write a header that shall be compatible with C (the `#ifdef __cplusplus extern "C"` stuff), you *still* can use this trick... – Aconcagua Aug 29 '18 at 08:35
  • @Aconcagua cool thanks :) ... re: "not by design" fair point, and I always thought that was a bit of a hack! – code_fodder Aug 29 '18 at 08:44