C#

Scott Dorman wrote:

The fact that C# implements a foreach iterator was done mostly as a convenience for the developer more than anything else.

Scott Dorman wrote:

The rules for implementing the generic IEnumerable<t> exist that way because IEnumerable<t> implements the IEnumerable interface.

Taka Muraoka wrote:

Given that this kind of feature is pretty standard in modern languages, I'd say it's perhaps a little more than a developers' convenience.

Taka Muraoka wrote:

This is the one that really baffles me. The generic GetEnumerator() doesn't appear to get called so I don't quite see the point of having IEnumerable<t> at all.

Scott Dorman wrote:

I think what you will find behind the scenes in the IL is pretty much the same calls if you used a class that implemented IEnumerable or one that didn't. The code generated is still a call to GetEnumerator and then calls to GetCurrent.

Scott Dorman wrote:

The fact that foreach works without IEnumerable was probably done in order to provide the most flexibility. I wouldn't necessary say that it suggests "someone who doesn't really know what they are doing".

Scott Dorman wrote:

What are you using to determine that the generic GetEnumerator isn't being called?

Taka Muraoka wrote:

I haven't really bothered looking too deeply into IL but as a hard-core C++ guy, it certainly doesn't make any sense.

Taka Muraoka wrote:

Well, it doesn't really make any sense from a general OO point of view, either

Taka Muraoka wrote:

Just stepping through in the debugger. Modifying it in the code sample in my OP to return null seems to have no ill effects.

foreach (int n in (IEnumerable<int>)x)
{
   System.Console.WriteLine(n);
}

class X : IEnumerable<int>
{
    private List<int> mList = new List<int>();
    public X()
    {
        mList.Add(1); mList.Add(2); mList.Add(3);
    }
 
    IEnumerator<int> IEnumerable<int>.GetEnumerator()
    {
        return mList.GetEnumerator();
    }
 
   IEnumerator IEnumerable.GetEnumerator()
    {
        return mList.GetEnumerator();
    }
}

class X : IEnumerable<int>
{
    private List<int> mList = new List<int>();
    public X()
    {
        mList.Add(1); mList.Add(2); mList.Add(3);
    }
 
    public IEnumerator<int> GetEnumerator()
    {
        return mList.GetEnumerator();
    }
 
   IEnumerator IEnumerable.GetEnumerator()
    {
        return mList.GetEnumerator();
    }
}

Scott Dorman wrote:

1: Leave your class X defined as is, and change the call in the foreach loop to read

foreach (int n in (IEnumerable<int>x)
{
   System.Console.WriteLine(n);
}

Scott Dorman wrote:

2: Leave the foreach call as is, and change X to read:

class X 
{
    private List<int> mList = new List<int>() ;
    public X() { mList.Add(1) ; mList.Add(2) ; mList.Add(3) ; }
    public IEnumerator GetEnumerator() { return mList.GetEnumerator() ; }
}

foreach ( X n in x ) // nb: iterate using an X, not an int
    System.Console.WriteLine( n ) ;

Taka Muraoka wrote:

This is obviously kinda ugly. The intent of deriving from IEnumerable<t> is to enforce type-safety and I was hoping that the compiler would be smart enough to realize that X can only be iterated over using int's and nothing else.

Taka Muraoka wrote:

Both these work but there are still some oddities.

Taka Muraoka wrote:

But using the modified foreach with either of your #2 code samples doesn't even compile ("Cannot convert int to X"). So it seems that there's now no way to get into the non-generic GetEnumerator()

Taka Muraoka wrote:

I don't particularly want to but it annoys me that I have to define this method but it never gets used

Taka Muraoka wrote:

So, it looks like foreach is ignoring whether the object it's iterating over derives from IEnumerable or IEnumerable<T> and just looks for a public GetEnumerator() method (which is kinda lame). But then how does it know which GetEnumerator() to use in your 2a code? Both of them are public in their respective interfaces, and yes, I tried reversing the order they are defined in I was kinda hoping the compiler could infer which one to use by the type being used in the foreach statement but for some reason, it's only allowing the generic one to be used.

Scott Dorman wrote:

By deriving X from IEnumerable<int> you are effectively telling the type system that when you enumerate over X (by calling GetEnumerator) that you are returning a type of int not X. Isn't that the point of providing the strongly typed version? You (and the compiler) know at compile time what the data type will be, so there is no need for it to call the non-typed version.

Scott Dorman wrote:

If you derive from an interface you have to implement all of the methods defined in the contract.

Scott Dorman wrote:

The key is which method is defined explicitly or implicitly.

Scott Dorman wrote:

When you declare one of them as public you are telling the compiler that this is the one you want to use by default.

public IEnumerator GetEnumerator() { ... }

public IEnumerator IEnumerable.GetEnumerator() { ... }

Taka Muraoka wrote:

That's right, this is the behaviour I want but I was playing with the code you gave because I wanted to get a better handle on what was really going on. I was wondering if the non-generic GetEnumerator() would get called if I tried to iterate using something other than int's.

Taka Muraoka wrote:

If I write a C++ class that derives from an interface that in turn derives from another interface, my class has to effectively implement two interfaces. This is reinforced by the fact that I have to implement both versions of GetEnumerator().

public IEnumerator GetEnumerator() { ... }

class X : IEnumerable<int>
{
    private List<int> mList = new List<int>();
    public X()
    {
        mList.Add(1); mList.Add(2); mList.Add(3);
    }
 
    public IEnumerator<int> GetEnumerator()
    {
        return mList.GetEnumerator();
    }
 
    IEnumerator IEnumerable.GetEnumerator()
    {
        return mList.GetEnumerator();
    }
}

Taka Muraoka wrote:

The fact that your 2b code works really makes me think foreach is ignoring the interface hierarchy and just looks for a public GetEnumerator() method. But on the other hand, the generic GetEnumerator() definition in 2b must be equivalent to the one in 2a (i.e. 2 different ways of defining the same thing, otherwise the compiler would be complaining about an un-implemented interface method) but so then, why does declaring it public make a difference?!

Taka Muraoka wrote:

why does declaring it public make a difference?!

Taka Muraoka wrote:

I thought you couldn't change the access privilege when implementing interface methods? So both X's GetEnumerator's are already public, because that's how they're defined in their respective interfaces.

Taka Muraoka wrote:

Having this compile...but not this...just seems bizarre to me Unless the former is a brand new definition of GetEnumerator() that has nothing to do with either of the two interfaces (hence my suspicion foreach is ignoring them).

Taka Muraoka wrote:

Aaargh, now I'm really confused

Scott Dorman wrote:

Defining the member in an interface doesn't imply that it is virtual at all.

interface I
{
    void foo( string msg ) ;
}

class A : I
{
    public void foo( string msg ) { System.Console.WriteLine( msg+" -> A::foo" ) ; }
}

class B : A
{
    public void foo( string msg ) { System.Console.WriteLine( msg+" -> B::foo" ) ; }
}

static void Main()
{
    B b = new B() ;
    ((I)b).foo( "Static type I" ) ;
    ((A)b).foo( "Static type A" ) ;
    ((B)b).foo( "Static type B" ) ;
}

--- OUTPUT ---
Static type I -> A::foo
Static type A -> A::foo
Static type B -> B::foo

class B : A,I
{
    void foo( string msg ) { System.Console.WriteLine( msg+" -> B::foo" ) ; }
}

--- OUTPUT ---
Static type I -> A::foo
Static type A -> A::foo
Static type B -> A::foo

class B : A,I
{
    public void foo( string msg ) { System.Console.WriteLine( msg+" -> B::foo" ) ; }
}

--- OUTPUT ---
Static type I -> B::foo
Static type A -> A::foo
Static type B -> B::foo

class B : A,I
{
    void foo( string msg ) { System.Console.WriteLine( msg+" -> B::foo" ) ; }
    void I.foo( string msg ) { System.Console.WriteLine( msg+" -> B::foo 2" ) ; }
}

--- OUTPUT ---
Static type I -> B::foo 2
Static type A -> A::foo
Static type B -> A::foo

class B : A,I
{
    public void foo( string msg ) { System.Console.WriteLine( msg+" -> B::foo" ) ; }
    void I.foo( string msg ) { System.Console.WriteLine( msg+" -> B::foo 2" ) ; }
}

--- OUTPUT ---
Static type I -> B::foo 2
Static type A -> A::foo
Static type B -> B::foo

Scott Dorman wrote:

I am explicitly implementing the IEnumerable.GetEnumerator member. In the calling code, it will default to using the implicit implementation (the public IEnumerator<int> GetEnumerator()) because the call isn't being cast to IEnumerable.

Scott Dorman wrote:

hopefuly my answers above make it clearer as to why declaring one of the methods public makes a difference.

keisal wrote:

would java or C++ be more help for me when it comes to c# programming?

<br />
		public string Reverse(string x)<br />
		{<br />
			char[] charArray = new char[x.Length];<br />
			int len = x.Length - 1;<br />
			for (int i = 0; i <= len; i++)<br />
				if(char.IsNumber())<br />
				{<br />
					<br />
				}<br />
				charArray[i] = x[len-i];<br />
			return new string(charArray);<br />
		}<br />

BREdwards wrote:

Lookup? As in a select case statement?

BREdwards wrote:

I suppose my next dilemma is trying to figure out what goes into that if statement, I believe my best bet is some sort of select case statement, though the last time I tried that resulted in error. And I'm still trying to figure out what to about the IsNumber(), or rather what I need to put between those parenthesis.

<br />
		public string Reverse(string x)<br />
		{<br />
			int i;<br />
			char[] charArray = new char[x.Length];<br />
			int len = x.Length - 1;<br />
			for ( i = 0; i <= len; i++)<br />
				if(char.IsNumber(x,i))<br />
				{<br />
					switch(i)<br />
					{<br />
						case'0':<br />
							x.Replace("0","zero");<br />
								break;<br />
					}<br />
				}<br />
				charArray[i] = x[len-i];<br />
			return new string(charArray);<br />
		}<br />