warning CS0168: The variable 'el' is declared but never used?

[kellyatdentrix]

Suppose that I just want to count the elements in a collection, so I do
this:

int i = 0;
foreach (MyElement el in MyCollection)
{
i++;
}
return i;

Is there any way in the 2003 compiler to avoid the warning:
warning CS0168: The variable 'el' is declared but never used?

I don't want to turn off the warning (can't anyway in VS 2003) I want
to fix the code without doing something wasteful...

Thanks!

And yes, I do know that you could just get the length of the
collection... my real example is a bit more complex than that presented
here.

-Kelly

 

[DKode]

use a for loop instead of a foreach loop:

int count = 0;
int i;
for (i = 0; i<MyCollection.Count; i++) {
count++;
}

return count;

that should work

 

[Bruce Wood]

Could you give more details about the "real example"?

Trying to think of a situation in which you would want to iterate over
the members of a collection but not actually do anything with the
individual members is giving me a headache. If you could give more
details, perhaps it would help my dearth of imagination.

 

[DKode]

lol, thats funny. it was starting to give me a headache as well

 

[kellyatdentrix]

Could you give more details about the "real example"?

Trying to think of a situation in which you would want to iterate over
the members of a collection but not actually do anything with the
individual members is giving me a headache. If you could give more
details, perhaps it would help my dearth of imagination.

Ok, sure. In the real example, there is an iterator. The iterator is
incredibly complex, skipping items in the real collection depending on
a huge number of variables. I want to know how many items will be
iterated over prior to the iteration beginning for various reasons. So
basically, I'm wanting to know how many items there are, but Count
won't work because many items in the actual collection will be skipped
according to user preferences, and many other business rules.

So I want a Count, but based on how many items the iterator will visit,
not how many items are actually in the collection.

All I really want to do is get rid of the warning without disabling the
warning. For exception handling, you can do this by getting rid of the
declaration. For example:

try
{
// something
}
catch(SomeException) // no declaration
{
// so something, but without looking at the exception.
}

If I try a similar approach with foreach, it doesn't compile:

foreach (Element in MyCollection) // doesn't compile.
{
}

Does that help?

-Kelly

 

[kellyatdentrix]

use a for loop instead of a foreach loop:

int count = 0;
int i;
for (i = 0; i<MyCollection.Count; i++) {
count++;
}

return count;

that should work

If it were a simple collection, it would. But I have a complex iterator
that I'm using to iterate over only SOME members of a complex
collection. I just want to know how many will be iterated over without
the compiler warning. The for won't work in this case.

-Kelly

 

[Jon Skeet [C# MVP]]

Ok, sure. In the real example, there is an iterator. The iterator is
incredibly complex, skipping items in the real collection depending on
a huge number of variables. I want to know how many items will be
iterated over prior to the iteration beginning for various reasons. So
basically, I'm wanting to know how many items there are, but Count
won't work because many items in the actual collection will be skipped
according to user preferences, and many other business rules.

So I want a Count, but based on how many items the iterator will visit,
not how many items are actually in the collection.

So you could do:

int count=0;
for (IEnumerator iterator = MyCollection.GetEnumerator();
iterator.HasNext;
iterator.MoveNext())
{
count++;
}

That's doing what C# would be doing under the covers (barring disposal
of the enumerator) and it makes it clearer why you're doing it. It's
more code, but it's clearer in terms of intent, IMO.

 

[Bruce Wood]

Does that help?

Oh, yes. Tremendously, thanks. That's why I love this forum: I learn
something new every day.

 

[Ken Wilson]

lol, thats funny. it was starting to give me a headache as well

On the other hand, I'm slowly working my way through the, ahem, hard
work you two have already done and I'm having a giggle. ;-)

Ken Wilson
Seeking viable employment in Victoria, BC

 

[Daniel O'Connell [C# MVP]]

Ok, sure. In the real example, there is an iterator. The iterator is
incredibly complex, skipping items in the real collection depending on
a huge number of variables. I want to know how many items will be
iterated over prior to the iteration beginning for various reasons. So
basically, I'm wanting to know how many items there are, but Count
won't work because many items in the actual collection will be skipped
according to user preferences, and many other business rules.

So I want a Count, but based on how many items the iterator will visit,
not how many items are actually in the collection.

While its not a direct answer to your question, why not just filter the
collection down in successive layers? That will give you a complete
collection at the otehr end with all the benefits of a collection. I can't
help thinking that a complicated iterator is going to be hard to maintain
and pehaps a risky spot, performance wise.

 

[Otis Mukinfus]

Ok, sure. In the real example, there is an iterator. The iterator is
incredibly complex, skipping items in the real collection depending on
a huge number of variables. I want to know how many items will be
iterated over prior to the iteration beginning for various reasons. So
basically, I'm wanting to know how many items there are, but Count
won't work because many items in the actual collection will be skipped
according to user preferences, and many other business rules.

So I want a Count, but based on how many items the iterator will visit,
not how many items are actually in the collection.

All I really want to do is get rid of the warning without disabling the
warning. For exception handling, you can do this by getting rid of the
declaration. For example:

try
{
// something
}
catch(SomeException) // no declaration
{
// so something, but without looking at the exception.
}

If I try a similar approach with foreach, it doesn't compile:

foreach (Element in MyCollection) // doesn't compile.
{
}

Does that help?

-Kelly

Why do you want to get rid of the warning in the first place?

Otis Mukinfus
http://www.otismukinfus.com
http://www.tomchilders.com

 

[Jon Skeet [C# MVP]]

Why do you want to get rid of the warning in the first place?

I don't know about Kelly, but I view warnings as errors - I don't allow
my code to compile with warnings. Because *some* warnings are
definitely significant, you want to make sure you don't have any of
those - and the easiest way of doing that is to ensure that there are
never any warnings at all.

 

[Otis Mukinfus]

I don't know about Kelly, but I view warnings as errors - I don't allow
my code to compile with warnings. Because *some* warnings are
definitely significant, you want to make sure you don't have any of
those - and the easiest way of doing that is to ensure that there are
never any warnings at all.

Normally I would agree 100% Jon. But with that error I'd be tempted
to let it slide, or as many have suggested, do the process another
way. He is using foreach as convenience anyway (as we all do).

Couldn't one loop through each element of the list and check it's type
in order to do what he wants? There's probably a case to be made
against that too (speed comes to mind) ;o)

Otis Mukinfus
http://www.otismukinfus.com
http://www.tomchilders.com

 

[Jon Skeet [C# MVP]]

Normally I would agree 100% Jon. But with that error I'd be tempted
to let it slide, or as many have suggested, do the process another
way. He is using foreach as convenience anyway (as we all do).

The trouble is that if you let even one warning slide, it's harder to
tell when you get more - especially when you then find that there are a
few other things that you might as well let slide to the same amount,
for instance. You soon get into the stage where you can't *really
easily* tell whether or not the code you've just added has introduced a
new warning. Much better to just be draconian to start with

Couldn't one loop through each element of the list and check it's type
in order to do what he wants? There's probably a case to be made
against that too (speed comes to mind) ;o)

More for duplication of code reasons, I'd say. It sounds like Kelly
already has that code somewhere, so we might as well make use of it
again...

 

[kellyatdentrix]

Couldn't one loop through each element of the list and check it's type

in order to do what he wants? There's probably a case to be made
against that too (speed comes to mind) ;o)

In this particular case, it's not an issue of type, it's an issue of
business object state.

Just to give a simplified taste of the problem, I'm iterating over
teeth and data about teeth in a mouth object, and I want to skip
missing teeth and such. I might also skip teeth (or certain information
about the tooth) based upon states of the user interface (stuff hidden
and such) or some pretty complex user preferences. Whether the tooth is
missing comes from yet another object, so I don't have a collection, I
have a set of business object states. I have six classes involved in
the iteration computation, many many hundreds of lines of code.

It's not one of the more simple cases you run into in the normal course
of dealing with objects. The actual logic is brutally complex. Just
GetNext is 43 lines of code. It's ugly stuff.

By the way, I really liked the solution of using the
enumerator/iterator directly. I'll probably just do that. Thanks!

-Kelly

 

[kellyatdentrix]

Normally I would agree 100% Jon. But with that error I'd be tempted
to let it slide, or as many have suggested, do the process another
way. He is using foreach as convenience anyway (as we all do).

Couldn't one loop through each element of the list and check it's type
in order to do what he wants? There's probably a case to be made
against that too (speed comes to mind) ;o)

The problem is that these spurious warnings can mask serious issues. If
I get rid of the spurious warnings, then I can see the warnings that I
care about. If there are spurious warnings, then one I care about could
be lurking in the list, and I wouldn't see it as something that needed
immediate attention.

-Kelly

 

[Otis Mukinfus]

The problem is that these spurious warnings can mask serious issues. If
I get rid of the spurious warnings, then I can see the warnings that I
care about. If there are spurious warnings, then one I care about could
be lurking in the list, and I wouldn't see it as something that needed
immediate attention.

-Kelly

All good reasoning gentlemen.

Otis Mukinfus
http://www.otismukinfus.com
http://www.tomchilders.com