Assigned but never used

[tshad]

I am getting the following error (VS2003):

The variable 'ktr' is assigned but its value is never used

How do I tell the compiler to ignore this? You used to have to use a Pragma
statement in C++ to do this.

Thanks,

Tom

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

By default this is just a warning, go to Project properties and check in the
Build the status of both "Warning levels " & "Treat warnings as error"

cheers,

 

[Chris Jobson]

Hi,

By default this is just a warning, go to Project properties and check in
the Build the status of both "Warning levels " & "Treat warnings as error"

There is also a "Suppress specific warnings" setting, which should do the
trick.

Chris Jobson

 

[rossum]

I am getting the following error (VS2003):

The variable 'ktr' is assigned but its value is never used

How do I tell the compiler to ignore this? You used to have to use a Pragma
statement in C++ to do this.

Thanks,

Tom

You have not shown your code, but it is not in general a good idea to
suppress any warnings. If a variable is assigned and not used then it
is best to rearrange the code so the warning is no longer given. By
suppressing that particular warning you are taking the risk of missing
the same error elsewhere when you amend the code and inadvertently
introduce the same thing in a different part of your code.

rossum



The ultimate truth is that there is no ultimate truth

 

[Doug Forster]

In my experience such a warning is virtually always a bug in the making so I
would NEVER suppress them or tolerate their presence. Why don't you correct
the code that generates the warning?

Cheers
Doug Forster

 

[tshad]

In my experience such a warning is virtually always a bug in the making so I
would NEVER suppress them or tolerate their presence. Why don't you correct
the code that generates the warning?

Because this warning is typically for a variable that I am temporarily
using, such as stemp, or itemp for use in testing. I will usually comment
out sections that I may uncomment later.

The variables take up little room and will hurt nothing.

Tom

 

[tshad]

Because this warning is typically for a variable that I am temporarily
using, such as stemp, or itemp for use in testing. I will usually comment
out sections that I may uncomment later.

The variables take up little room and will hurt nothing.

Also, I know what variables I am going to use, such as paxTotal,
paxSubTotal, paxGrandTotal, but I haven't used them yet. I always put my
variable definitions at the top of the subroutine, so if I know what
variables I will need (such as totaling a large grid), I will usually assign
all the variables when I build the routine.

The problem with these warnings, is I could have 10 or more of them when I
build the project, and is not apparent whether there really is a problem as
the real errors are mixed with the warnings.

Tom

 

[Bill Butler]

"tshad" <[email protected]> wrote in message news:[email protected]...

Also, I know what variables I am going to use, such as paxTotal, paxSubTotal, paxGrandTotal, but I
haven't used them yet. I always put my variable definitions at the top of the subroutine, so if I
know what variables I will need (such as totaling a large grid), I will usually assign all the
variables when I build the routine.

The problem with these warnings, is I could have 10 or more of them when I build the project, and
is not apparent whether there really is a problem as the real errors are mixed with the warnings.

I generally just comment them out at that point to stop the warning.
When you are ready to use the variable you simply uncomment it.

Bill

 

[tshad]

I generally just comment them out at that point to stop the warning.
When you are ready to use the variable you simply uncomment it.

I've done the same. I just find it more convenient to list them out and
they are there when necessary.

As I mentioned, I use are temporary variables, such as iktr or itemp or
stemp that are used to quickly test something and I really don't want to
comment and uncomment when needed or not needed. Ans since it causes no
problem, why not.

Tom