Question

I'm working on a Windows Store app and just bumped Visual Studio's warn level up to 4, so I've been fixing unreferenced parameter warnings. In the process, I've noticed that unreferenced framework-managed parameters (^) do not generate a C4100 warning like other unreferenced "formal" parameters. To illustrate what I mean:

void Method(CNonFrameworkManaged* pObject)
{
    // Warning C4100: 'pObject' : unreferenced formal parameter
}

void Method(CFrameworkManaged^ spObject)
{
    // No warning
}

Why is it that the second does not generate the warning? And is there a way to turn on such warnings? I want my code to appear consistent but tracking all of these down by hand would take days..

Note: I'm compiling my project without CLR support, but it seems like these should still be detectable.

Was it helpful?

Solution

A hat type is a form of smart pointer, so each hat type has a destructor, which releases ownership of the pointed-to object. While spObject is not referenced by name in your source code, the object is referenced by the compiler-generated call to the destructor at the end of the function.

When the compiler checks for unreferenced local variables, it finds this reference and does not issue the warning. An ordinary (non-parameter) local variable must have a name, and it would be problematic if the compiler issued "unreferenced local variable" warnings for such local variables that exist solely to be destroyed (e.g., RAII types like lock_guard). Warnings C4101 and C4189 are issued for unreferenced non-parameter local variables. (Could the compiler treat parameters differently? Possibly. But it doesn't.)

Observe that C4100 is not issued for any parameter of a type that has a destructor:

struct A { };
struct B { ~B() { } };

void f(A a) { } // C4100 is issued for 'a'
void f(B b) { } // C4100 is not issued for 'b'
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top