G++ Does Not Show a 'Unused' Warning

g++ does not show a 'unused' warning

It is not a primitive value, so its constructor and/or destructor might have desired side effects.

To illustrate that this happens in practice: I use a class to time sections of code, that looks roughly like this:

class Timed {
double start;
public:
Timed() { start = now(); }
~Timed() { std::cout << (now() - start) << '\n'; }
}

So to measure how long a function takes, I simply do:

void slow() {
Timed t;
// heavy operation here...
}

The variable t never gets used, but it's still important to the behaviour of the code.

GCC and Clang not warning on unused exception variable

Clang

Bug report: https://bugs.llvm.org/show_bug.cgi?id=41746

It turns out that clang has the warning -Wunused-exception-parameter, although it is not activated by any of the groups -Wall, -Wextra, or -Wunused.

GCC

Bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90353

As noted in a comment to this question and in the bug report, all catch parameters are always marked as used. This is being investigated in the linked bug report.

Why is there no gcc/g++ warning for unused temporaries?

Compiler doesn't issue a warning, because it's quite possible that you might be updating some static-member / global variable inside the constructor (which is valid and meaningful). e.g.:

struct A
{
static int count;
A () { count ++; }
};

Now when you simply invoke a temporary:

A();

In case if such update is not happening, compiler will not dig into the constructor of A and check if something useful is happening. It always assumes to be a valid scenario. There are many such cases can be pointed out related to temporaries.

Compilation warning not present (GCC and g++)

As far as the language is concerned, there's no error - a statement is not required to have a side effect.

However, since a statement that does nothing is almost certainly a mistake, most compilers will warn about it. Yours will, but only if you enable that warning via the command line arguments.

You can enable just that warning with -Wunused-value, but I suggest you enable a decent set of warnings (including this one) with -Wall -Wextra.

As you found, this will also give a warning that the function parameters are unused. Since this is main, you can easily fix it by changing the signature to not have any parameters:

int main()

More generally, to avoid the warning if you need to ignore parameters, C++ allows you not to name them:

int main(int, char**)

and both languages allow you to explicitly use but ignore the value

(void)argc;
(void)argv;

G++ Unused Label Warning for Preprocessor Macro

from what I can tell, the initialize label is passed to __TRACE__ where it's used as an argument for a printf() call.

No, it is not, actually. The x parameter of STATE() is not the same as the x parameter of __TRACE__().

In the statement STATE(initialize), the x parameter is initialize, so x: becomes simply initialize: (the label in question), but #x stringifies the input value of x as "initialize" in this case, so STATE(initialize) expands to this:

initialize: __TRACE__("enter", "initialize");

And then, in the __TRACE__ macro, the y parameter is "enter" and the x parameter is "initialize", so __TRACE__("enter", "initialize") expands to this:

dbg.printf(DebugIO::debug2,"FSM:" "enter" "(" "initialize" ")\n");

And lastly, string literals that are separated by only whitespace are merged together by the compiler, so the final code for STATE(initialize) looks like this:

initialize: dbg.printf(DebugIO::debug2,"FSM:enter(initialize)\n");;

And since there is no goto or other statement that references the initialize label, that is why you get a warning about it.

How would I correct this?

Unless there is an actual goto initialize statement in the code somewhere, I would just get rid of the label altogether:

#define STATE(x)    __TRACE__("enter", #x);

How do you disable the unused variable warnings coming out of gcc in 3rd party code I do not wish to edit?

The -Wno-unused-variable switch usually does the trick. However, that is a very useful warning indeed if you care about these things in your project. It becomes annoying when GCC starts to warn you about things not in your code though.

I would recommend you keeping the warning on, but use -isystem instead of -I for include directories of third-party projects. That flag tells GCC not to warn you about the stuff you have no control over.

For example, instead of -IC:\\boost_1_52_0, say -isystem C:\\boost_1_52_0.

Hope it helps. Good Luck!

How to get g++ to warn on unused member variables

I'm not aware of any such warning. Additionally I'll speculate that the reason it doesn't exist is because it can't be reliably generated in all cases, so they elected to not spend effort making it work for some subset of cases. For example, if the class friends another function that's in a library, the compiler would have no way of knowing if that library mutated any particular class attribute or not.

How do I best silence a warning about unused variables?

You can put it in "(void)var;" expression (does nothing) so that a compiler sees it is used. This is portable between compilers.

E.g.

void foo(int param1, int param2)
{
(void)param2;
bar(param1);
}

Or,

#define UNUSED(expr) do { (void)(expr); } while (0)
...

void foo(int param1, int param2)
{
UNUSED(param2);
bar(param1);
}

g++-5.1.1 warns about unused variable only when optimization flag is used

This looks like a bug, if we look at the documentation for -Wunused-variable it says (emphasis mine):

This option implies -Wunused-const-variable for C, but not for C++

and if we look at -Wunused-const-variable it says:

Warn whenever a constant static variable is unused aside from its
declaration. This warning is enabled by -Wunused-variable for C, but
not for C++. In C++ this is normally not an error since const
variables take the place of #defines in C++.

and we can see this warning goes away in the head revision of gcc.

This gcc bug report: -Wunused-variable ignores unused const initialised variables is also relevant. Although it is against C the C++ case is also discussed.



Related Topics



Leave a reply



Submit