|
take a look at the List<T>
declaration:
public class List<T> : IList<T>, ICollection<T>,
IEnumerable<T>, IList, ICollection, IEnumerable
i guess that the compiler generates a interface from IEnumerable<IGenericInterface> and makes all types generated for types that implement IGenericInterface implement that interface, so they are interchangeable.
think like this:
you have a Class A that implements interface I, and a Class B that also implements that interface, you can't write:
A a = new A();
B b = new B();
a = b;
because, although they implement the same interface, they are not the same type.
i think the same concept can be applied to List<A> and List<I>, they are both types that implement IEnumerable<I>, but aren't the same type.
what i really need to search more it's this case:
public IList<IGenericInterface> GetStuff()
{
return new List<UsingGenericInterface>();
}
at this moment, i can't explain why it didn't work, but i'll discover
EDIT: i've forgotten about the < and > 
|
|
|
|
|
One other reason not mentioned is that returning IEnumerable or IEnumerable<T> is a requirement for using iterator blocks (yield keyword)  .
|
|
|
|
|
but this was accomplished by returning an IList<T>, given that IList<T> inherits from IEnumerable<T>, or not?
|
|
|
|
|
SledgeHammer01 wrote: returning IEnumerable or IEnumerable<T> is a requirement for using iterator blocks
A very interesting reply, thanks +5.
This is an area where I think I am a bit "stuck" in my grokking of "yield" (waterboarding myself frequently in Skeet's "C# in Action" is not seeming to help me ferret out the plot).
If you care to comment further on this, that would be appreciated.
thanks, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
Just a shortcut. Instead of implementing a full blown enumerator, you can just do something like:
public IEnumerable<int> GetEnumerator()
{
for (int i = 0; i < 100; i++)
yield return i;
}
foreach on the returned IEnumerable<int> will work on that just as expected:
foreach (int i in GetEnumerator())
{
System.Diagnostics.Writeline(i);
}
|
|
|
|
|
Let's take this question ... an interesting one ... into the "Twilight Zone:"
public IEnumerable<IGenericInterface> GetStuffX()
{
return (new List<UsingGenericInterface>()) as IEnumerable<IGenericInterface>;
}
public IEnumerable<UsingGenericInterface> GetStuffY()
{
return (new List<IGenericInterface>()) as IEnumerable<UsingGenericInterface>;
}
Why do these compile ?
best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
List<T> implements IEnumerable<T>.
|
|
|
|
|
BillWoodruff wrote: Why do these compile ?
MSDN:
"The as operator is like a cast operation. However, if the conversion is not possible, as returns null instead of raising an exception." link to the "as" operator in msdn[^]
so, what happens is that the compiler doesn't care if your conversion always returns null.
i'm trying to instal the .net sdk in this computer (don't have admin privileges) to disassemble a dll and see what code the compiler generates for List<IGenericInterface> and for List<UsingGenericInterface> but i suppose that the List<IGenericInterface> implements IList<IGenericInterface> and IEnumerable<IGenericInterface> while List<UsingGenericInterface> implements IList<UsingGenericInterface>, IEnumerable<UsingGenericInterface> and, given that UsingGenericInterface implements IGenericInterface, the List<UsingGenericInterface> also implements IEnumerable<IGenericInterface>
if this is the case, then i think it's a design flaw of the compiler, but i wont take precipitated conclusions.
|
|
|
|
|
My apologies, Jasnoch, and Sentenryu; I do know why they compile, and how "as" functions compared to "casting to Type;" in this case I just thought it would be more interesting to "round out" the possibilities listed.
It was not my intent to divert attention from the main focus of your thread.
best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
The short answer is because T on IEnumerable<T>[^] is declared covariant, and the one on IList<T> isn't.
I don't really understand why lists and other collection classes don't have covariant type parameters as well; I guess there must be some problems with implementing it.
|
|
|
|
|
Hi, I'm a beginning C# programmer.
I'm playing with a RichTextBox, applying various colors to the lines. I've noticed that there is a property of the RTB called TextLength. In my testing RTB.TextLength is ALWAYS equal to RTB.Text.Length. So why even have such a property? Everyone knows you can get a String.Length, so why the redundancy?
Originally I thought RTB.TextLength might have something to do with formatting characters vs visible characters but this is apparently not the case.
|
|
|
|
|
Oh nevermind, I think I see now. RTB.Text probably pulls out all that text to a separate copy in memory, THEN takes the length. RTB.TextLength probably doesn't have that overhead. Am I right?
|
|
|
|
|
Yes, TextLength is nothing but the length of the Text property and should be used when you want to obtain the length of the text, and not get at the text for any other purpose.
/ravi
|
|
|
|
|
When i read the image it shows the incorrect output in other language not in english. here is the code for read the image..
MODI.Document modDoc = new MODI.Document();
modDoc.Create(@"h:\123.jpg");
modDoc.OCR(MODI.MiLANGUAGES.miLANG_ENGLISH, true, true);
MODI.Image img = (MODI.Image)modDoc.Images[0];
MODI.Layout layout = img.Layout;
String OCRText = layout.Text;
modDoc.Close(false);
for (int i = 0; i < lines.Length; i++)
{
textBox1.Text = textBox1.Text + lines[i];
textBox1.Text += '\n';
}
Plz anybody tell me the solution of this problem .........
|
|
|
|
|
Please do not post the same question twice.
Please delete the other one, before someone answers it.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
When i read the image it shows the incorrect output in other language not in english. here is the code for read the image..
MODI.Document modDoc = new MODI.Document();
modDoc.Create(@"h:\123.jpg");
modDoc.OCR(MODI.MiLANGUAGES.miLANG_ENGLISH, true, true);
MODI.Image img = (MODI.Image)modDoc.Images[0];
MODI.Layout layout = img.Layout;
String OCRText = layout.Text;
modDoc.Close(false);
for (int i = 0; i < lines.Length; i++)
{
textBox1.Text = textBox1.Text + lines[i];
textBox1.Text += '\n';
}
Plz anybody tell me the solution of this problem .........
|
|
|
|
|
I would like clipping a line but do not know, you can help me?
Such LiangBarsky algorithm used to cut the line is drawn by Bresenham.
|
|
|
|
|
Hello Everyone
I'm trying to create a small project in my laptop. Could someone please tell me once this application is up and running is there a possibility to access this application via bluetooth on to my mobile phone.
Please feel free to correct if my question is not at clear explonation...
Kind regards
Roni
|
|
|
|
|
Define "access"?? That's such a generic term it really has no meaning.
1. Do you want to run the application on the phone? Not going to happen.
2. Do you want something on the phone to communicate with your application? Sure. You just need to define what protocols you're going to use and what you want to transfer over this link.
3. Do you want this application to send some kind of data to the phone? Sure, see number 2.
|
|
|
|
|
Greetings.
I am currently working on a little project for fun; I am trying to have a webcam work in C#, probably by using directshow.
But I am so clueless!
I don't understand the code enough to write my own from scratch so I am seeking someone who masters C# to show Me what I need.
This would work best on MSN; ADEPofArts@gmail.com
Thank You for your help.
|
|
|
|
|
You might get a better response if you post this in this forum:
Collaboration and Beta Testing[^]
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Ah! Didn't see that one. Thanks.
|
|
|
|
|
You should also remove your email from your post so you don't get a ton of spam.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
For some reason got on a Tree class kick (tree, btree, bstree, avltree, etc). So I started porting an old MFC version I wrote 10yrs ago and decided instead to redesign it.
Concept I'm going for at this point is I'll have a base Node object, a NodeCollection and a Tree class. The btree will derive from tree, the bstree will derive from btree and the avl tree will derive from bstree.
Right now... everything looks something like:
public class Node<T>
{
public Node(T value)
{
_value = value;
}
public NodeCollection Children
{
get
{
return _children;
}
}
}
public class NodeCollection : Collection<T>
{
}
public class Tree
{
public Node Root
{
get
{
return _root;
}
set
{
_root = value;
}
}
}
Obviously, I snipped out the non important stuff for brevity, but one thing I'm not liking so far is that is that you need to do something like tree.Root.Value, tree.Root.Children[4].Value, etc to get to the real value. I.e. everything works on a Node object instead of the value object. I guess you do need a Node object so you can have somewhere to get the children from. Perhaps if I add some methods to NodeCollection to find Nodes by Value it will make it better?
Any suggestions, I'm not liking something about this design, but I'm not quite sure what it is.
My C++ version sort of hid all that by using the Windows POSITION thingy... which I guess is pretty much the same this as just returning a Node... Hmmm...
|
|
|
|
|
SledgeHammer01 wrote: Perhaps if I add some methods to NodeCollection to find Nodes by Value it will
make it better?
Hmmmm. One thought occurs to me - what happens if the value you want to return is in the root node? You'd have to check that value first, and then call the NodeCollection check. If the check is part of the Node instead, and that knows how to iterate over child nodes then that would simplify the end code somewhat (granted it would make the internal logic slightly more complex). Actually, a simple extension to this would allow you to put it into the Tree class itself, and then that would trigger the Node/NodeCollection checks - this way, the end dev only has to use something like:
var node = myTree.FindNodeByValue(myValue); Thinking this through though, there is a particular smell in place in that you actually have to supply a full copy of value that can be used in an equality test - perhaps you could extend to include an equality test as well (as a Predicate for instance), so that complex objects could be retrieved off one of their properties (useful if you want to search for a particular ID for instance).
As for the retrieving by child position, this code seems very reminiscent of manipulating XML. Again, things could be made simpler by providing methods at the Tree level which would retrieve the relevant child without having to resort to the Root node in external code. As this is all working off a Node object, you could have a method that looks something like this (completely untested, so there may be some kinks in it):
public Node<T> GetNodeByPosition(int position)
{
return this.Root.Children[position];
}The Node class could have a similar method, which would allow the dev to chain results together.
Anyway, these are just some thoughts off the top of my head - I'd really have to sit down and work through this some more.
[Edit]Not sure why your post was 1-voted. I don't see anything inherently wrong with the post.
modified 5-Jan-12 8:50am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
