I have already searched for it on MSDN and I read the definition that it is a non generic ....
but my problem is that i am not understanding what is its use and when to use it . So i hope that anyone can help me . Thanks .
In addition to the older code that doesn't know about generics, there are also a lot of cases where you know you have a list of data, but you can't know of what ahead of time. Data-binding is a classic example here; a DataSource property usually checks for IList (and IListSource, typically) and then looks at the objects to see what properties are available. It can't use generics in this case.
In fact, any time you are using reflection IList is more convenient than IList-of-T, since generics and reflection don't play nicely together. It can be done, but it is a pain. Unfortunately since IList-of-T doesn't derive from IList there are cases where this can fail - but it is a good 95% rule.
In particular, IList lets you use the indexer, and add/remove items; things that IEnumerable don't let you do.
Most app-level code (i.e. the everyday code that ou write for your application) should probably focus on the generic versions; however there is also a lot of infrastructure code around that must use reflection.
IList (non-generic version) is a leftover from C# version one, when we didn't have generics.
With C# 2 and .NET Framework 2.0, generics was added to the language and generic implementations of the collection types was added. Therefore, the non-generic versions was no longer needed, but they couldn't be removed from the framework, since it would make porting code from .NET 1.1 to 2.0 a pain.
Today, you almost always use IList<T>, the primary reason for IList to still be around is for reasons of backwards compatibility.
It is an interface that existed before generics were introduced in .NET 2.0.
It is there for backwards compatibility.
Use the generic version.
it is a interface , which is normally implemented by collection classes which is intended to provide list like method but in .net version less than 2.0 i.e. without generic introduction so if you are using framework version 1.0, 1.1 than you would see the usage of this IList
Related
Consider, for example, the method:
public static Attribute GetCustomAttribute(this ParameterInfo element, Type attributeType);
defined in System.Reflection.CustomAttributeExtensions
Wouldn't it make more sense to define instead:
public static T GetCustomAttribute<T>(this ParameterInfo element, T attributeType) where T : Attribute;
And save the casting?
The non-generic method of retrieving custom attribute is from the old .NET days when generics weren't implemented.
For current and future coding, you can take advantage of CustomAttributeExtensions.GetCustomAttributes<T> - if you're coding using .NET 4.5 version and above -.
Sadly - or maybe actually - software has a sequential evolution. I mean, there was a time where generic weren't with us (.NET 1.0 and 1.1), and there's a lot of code base that's inherited from early .NET versions, and because of framework team prioritzation it seems like not every method that would be better using a generic parameter(s) has been already implemented.
About inherited code
#BenRobinson said in some comment here bellow:
The point I was making was that these extension methods were added in
.net 4.5 (all of them not just the generic ones) and extension methods
were added after generics so non generic extension methods of any kind
have nothing to do with backwards compatibility with .net 1.0/1.1.
I'm adding this to avoid confusion: don't understand inherited code in terms of Microsoft not changing the non-generic code base because of backwards compatibility with third-party code.
Actually, I'm pointing out that current .NET version itself has a lot of code inherited from early .NET versions, either if the intention of Microsoft is maintaining backwards compatibility with third-party code or not.
I assume or guess that .NET Framework Team has prioritized new base class library (BCL) and satellite frameworks additions and some of members coming from pre-generics era are still as is because the change isn't worth the effort, or we could discuss if it's worth the effort and they did design decision mistakes, but StackOverflow isn't a discussion board, is it?
There is indeed a an overload that is equivalent to your example, GetCustomAttribute<T>(ParameterInfo), however to call this method without nasty reflection, you need to know the type of T at compile time. If you only know the type of T at run time then the equivalent method is GetCustomAttribute(ParameterInfo, Type)
Generics was added to the C# language in version 2. I believe that attributes was in the language at version 1 or 1.1 (can't remember which, I think it was in version 1 but I could be wrong).
This means that even though they would have saved a lot of unnecessary casting by changing all methods to use generics instead, they could have broken backwards compatability. And breaking backwards compatability is bad™.
Edit:
Also, I just thought about one more reason.
If you are writing reflection code it's often quite a hassle to call a generic method via reflection (C# has a really stupid api for doing so...) so if you are writing reflection code then using the non-generic version is in many cases much easier than using the generic one.
Edit again:
Damn, Ben Robinson beat me to the reflection point by a minute! :)
The title pretty much sums it up. Now that we have List<T>'s why would anyone want to use an ArrayList instead? The only reason I can think of is if you are forced to use an old version of .NET before List<T> was implemented?
As you said, if for some reason you are stuck with .Net 1.1 then you don't have a choice.
Your question seems to indicate that there is a choice. So then there is no reason to userArrayList. Anything that ArrayList can do, List<T> can do as well, if not better.
Short answer, no. ArrayList was from when .NET didn't support generics. List is the more flexible (generic) way to handle lists. In fact, I don't think Silverlight even supports ArrayLists at all.
ArrayList is mostly for backward compatibility. In a project when there is a deadline, you may have the time to convert everything from ArrayList to generic List.
Another reason is that you may be using a library that is written in .NET 1.1. So you may force to use ArrayList in your code, and most likely convert it to a generic List for easy coding.
However, there are some differences and you may want to read this:
.NET: ArrayList vs List
You said it yourself: backwards compatibility. There's no use for it any more, but it clearly can't be removed from the BCL as it'd break existing code that for whatever reason must be compiled against .NET 1.1.
The only time I've ever used an ArrayList since .Net 2.0 was for use with the built-in My.Settings feature in vb.net, and I've since learned I probably could have shoehorned a generic list in there.
I'm implementing some networking code using the selector pattern in C# / .NET 3.5. However, I was surprised to find that the Select method takes nongeneric IList's rather than IList<Socket>'s. It says clearly in the help documentation though that a list of sockets is expected here and nothing else.
Does anyone know why this is the case?
From the docs:
Supported in: 4, 3.5, 3.0, 2.0, 1.1, 1.0
That would have been a pretty interesting signature in .NET 1.0...
The signature can't be changed without breaking existing callers. They could have added an overload, but I'm not sure it would have helped very much - if you'd tried to use the "new" overload with the wrong argument types (e.g. List<string> instead of List<Socket>) it would just have bound to the old overload.
Socket.Select (which I assume you mean by Select) is a method that was already present in .NET 1.0, and Microsoft apparently never bothered to update it, probably because it is a quaint and seldom-used API.
I'm working on improving my skills in other languages, coming from using c++ as my primary programming language. My current project is hammering down C#.net, as I have heard it is a good in-between language for one who knows both c++ and VB.net.
Typically when working with an unknown number of elements in c++ I would declare my variable as a vector and just go from there. Vectors don't seem to exist in c#, and in my current program I have been using arraylists instead, but I'm starting to wonder if it's a good habit to use arraylists as I read somewhere that it was a carryover from .net 1.0
Long question short- what is the most commonly used listing type for c#?
If you target pre .NET 2.0 versions, use ArrayList
If you target .NET 2.0+ then use generic type List<T>
You may need to find replacements for other C++ standard containers, so here is possible mapping of C++ to .NET 2.0+ similar types or equivalents:
std::vector - List<T>
std::list - LinkedList<T>
std::map - Dictionary<K, V>
std::set - HashSet<T>
std::multimap - Dictionary<K, List<V>>
I would recommend you explore the System.Collections namespace, especially the System.Collections.Generics set of objects. The built-in functionality can be strongly typed across the various Lists, Dictionaries and NameValueCollections to provide you with a wide range of capabilities. They are also extendable so if they don't do EXACTLY what you need, you just extend them and add the new functionality.
That'd be List<T>, I suppose. ArrayList is the non-generic type and—as you correctly observed—a leftover from the .NET 1 times. Starting with .NET 2 you can use Generics and therefore List<T>.
Short answer: List<T>. You can find the docs here.
I'm working on a something related to roughset right now. The project uses alot of sets operation and manipulation. I've been using string operations as a stop gap measure for set operation. It has worked fine until we need to process some ungodly amount of data ( 500,000 records with about 40+ columns each ) through the algorithm.
I know that there is no set data structure in .net 2.0(2.0 was the latest when I started the project) I want to know if there is any library that offer fast set operation in .net c# or if 3.5 has added native set data structure.
Thanks .
.NET 3.5 already has a native set data type: HashSet. You might also want to look at HashSet and LINQ set operators for the operations.
In .NET 1.0, there was a third party Set data type: Iesi.Collections which was extended with .NET 2.0 generics with Iesi.Collections.Generic.
You might want to try and look at all of them to see which one would benefit you the most. :)
LINQ supports some set operations. See LINQ 101 page for examples.
Also there is a class HashSet (.NET 3.5)
Here is Microsoft guidelines for set operations in .NET:
HashSet and LINQ Set Operations
List of set operations supported by HasSet class:
HashSet Collection Type
Update: This is for .Net 2.0. For .Net 3.5, refer posts by aku, Jon..
This is a good reference for efficiently representing sets in .Net.
It may be worth taking a look at C5, it's a generic collection library for .NET which includes sets.
Note that I haven't looked into it much, but it seems to be a pretty fantastic collection library.
Try HashSet in .NET 3.5.
This page from a member of the .NET BCL team has some good information on the intent of HashSet
I have been abusing the Dictionary class in .NET 2.0 as a set:
private object dummy = "ok";
public void Add(object el) {
dict[el] = dummy;
}
public bool Contains(object el) {
return dict.ContainsKey(el);
}
You can use Linq to Objects in C# 3.0.
You ever think about sing F#? This seems like a job for a functional programming language.
You should take a look at C5 Generic Collection Library. This library is a systematic approach to fix holes in .NET class library by providing missing structures, as well as replacing existing ones with set of well designed interfaces and generic classes.
Among others, there is HashSet<T> - generic Set class based on linear hashing.