How can I reallocate memory of arrays in C#?
-
Yes it will work. Thanks for the idea :). I got another idea that ArrayList class. It is also a good method. right? Thanks & Regards, Hogan
Yes we may also use object of System.Collections.ArrayList class, this object acts as an array (although it is an object and not a real array) and will grow when you add new items to it. Therefore you have both options available:). -Dave.
Dave Traister, ComponentOne LLC. www.componentone.com
-
Yes we may also use object of System.Collections.ArrayList class, this object acts as an array (although it is an object and not a real array) and will grow when you add new items to it. Therefore you have both options available:). -Dave.
Dave Traister, ComponentOne LLC. www.componentone.com
Oh ok great :) Thanks to spend time with me. Regards, Hogan
-
Oh ok great :) Thanks to spend time with me. Regards, Hogan
ArrayList is something we used back in the old days before .NET got the necessary features to build collections. It's still there to support old code, but it's not something you should use for anything. The current collections are based on Generics and are much better (still severely lacking, but evetything they lack ArrayList lacks as well). You will find them in System.Collections.Generics. Using an Array for something where the size isn't static is inefficient - both to code and for the computer to execute. There is no excuse for it, it is simply not something you should ever do. The bottom line is that this is not a choice between an Array or an ArrayList - neither should be used in this case. Use System.Collections.Generic.List
-
How can I reallocate the memory for arrays. In VB I can use ReDim. The same way, is there any equal keyword in C#? Regards, Hogan
I think that feature is not get in C#.Please use arraylist.
Continue...
-
ArrayList is something we used back in the old days before .NET got the necessary features to build collections. It's still there to support old code, but it's not something you should use for anything. The current collections are based on Generics and are much better (still severely lacking, but evetything they lack ArrayList lacks as well). You will find them in System.Collections.Generics. Using an Array for something where the size isn't static is inefficient - both to code and for the computer to execute. There is no excuse for it, it is simply not something you should ever do. The bottom line is that this is not a choice between an Array or an ArrayList - neither should be used in this case. Use System.Collections.Generic.List
Thats another wonderful idea. Thank you buddy. Regards, Hogan
-
ArrayList is something we used back in the old days before .NET got the necessary features to build collections. It's still there to support old code, but it's not something you should use for anything. The current collections are based on Generics and are much better (still severely lacking, but evetything they lack ArrayList lacks as well). You will find them in System.Collections.Generics. Using an Array for something where the size isn't static is inefficient - both to code and for the computer to execute. There is no excuse for it, it is simply not something you should ever do. The bottom line is that this is not a choice between an Array or an ArrayList - neither should be used in this case. Use System.Collections.Generic.List
-
lmoelleb wrote:
still severely lacking, but evetything they lack ArrayList lacks as well
for example....
Events. These are critical to build ANY form of GUI on top of your domain model and they can be critical within the domain model itself as well. For example, how would you know you needed to write a new item to the database when it is added to the collection in the domain model if you do not get an event when it is added. Sure you can write your own collection class for it, but it is really something I would expect the framework to provide. They did add the BindableList and ObservableCollection (in .NET 3.0). ObservableCollection is as such OK, but: 1) Why do we have two implementations of a list collection with events, and no events on any other collection type? 2) Why are they separate in the first place? Just add the events to the standard collections and be done with it.
-
I think that feature is not get in C#.Please use arraylist.
Continue...
-
Events. These are critical to build ANY form of GUI on top of your domain model and they can be critical within the domain model itself as well. For example, how would you know you needed to write a new item to the database when it is added to the collection in the domain model if you do not get an event when it is added. Sure you can write your own collection class for it, but it is really something I would expect the framework to provide. They did add the BindableList and ObservableCollection (in .NET 3.0). ObservableCollection is as such OK, but: 1) Why do we have two implementations of a list collection with events, and no events on any other collection type? 2) Why are they separate in the first place? Just add the events to the standard collections and be done with it.
Seems like you are vigilant to upgrade your knowledge. :) Can you please refer me any articles or links which describe what is new in Framework 2.0 and 3.0? Regards, Hogan
-
Events. These are critical to build ANY form of GUI on top of your domain model and they can be critical within the domain model itself as well. For example, how would you know you needed to write a new item to the database when it is added to the collection in the domain model if you do not get an event when it is added. Sure you can write your own collection class for it, but it is really something I would expect the framework to provide. They did add the BindableList and ObservableCollection (in .NET 3.0). ObservableCollection is as such OK, but: 1) Why do we have two implementations of a list collection with events, and no events on any other collection type? 2) Why are they separate in the first place? Just add the events to the standard collections and be done with it.
OK, fine - but I still wouldn't call that "severely lacking". You've given an example of only 1 thing that is missing from one particular use case of a List (of which there are thousands of use-cases which don't require events) I can't say that im familiar with what you mean by "domain model", but ive used List and the other collection classes countless thousands of times without ever having the need for them to raise events when I add/remove items.
-
OK, fine - but I still wouldn't call that "severely lacking". You've given an example of only 1 thing that is missing from one particular use case of a List (of which there are thousands of use-cases which don't require events) I can't say that im familiar with what you mean by "domain model", but ive used List and the other collection classes countless thousands of times without ever having the need for them to raise events when I add/remove items.
"Severely lacking" is pretty accurate, but a bit on the mild side. "Pathetic" is another description that springs into mind. It does not matter how many things are missing, it matters how important the missing things are. If I gave you a collection that could do EVERYTHING except one small detail: You could never add items to it - would you then like it because it only missed one single fundamental feature? :) The user case I gave are: 1) Build a user interface. 2) Persist data. I will at any time claim that these use cases are so fundamental that it doesn't really matter it's only two (that I came up with, it's not like its the only usecases - basically you need events every single time data change). If you are not familier with Domain Models and Observer Pattern (you might simply call it something else - Google it and see if you recognize it) you might indeed not know how badly it is missing. The Big Ball of Mud pattern works just fine without events as you can compensate for it by adding even more spaghetti code.
-
"Severely lacking" is pretty accurate, but a bit on the mild side. "Pathetic" is another description that springs into mind. It does not matter how many things are missing, it matters how important the missing things are. If I gave you a collection that could do EVERYTHING except one small detail: You could never add items to it - would you then like it because it only missed one single fundamental feature? :) The user case I gave are: 1) Build a user interface. 2) Persist data. I will at any time claim that these use cases are so fundamental that it doesn't really matter it's only two (that I came up with, it's not like its the only usecases - basically you need events every single time data change). If you are not familier with Domain Models and Observer Pattern (you might simply call it something else - Google it and see if you recognize it) you might indeed not know how badly it is missing. The Big Ball of Mud pattern works just fine without events as you can compensate for it by adding even more spaghetti code.
Well Observer I know well, but its rarely my collection of objects that has the observer. I guess its just a different style I use. Still can't see how a simple object for "holding a collection of items" is severely lacking though :confused: As far as im concerned, it has Add/Remove/Count which is exactly what I think it should have. Again, just a different way of dealing with it I guess.
-
Well Observer I know well, but its rarely my collection of objects that has the observer. I guess its just a different style I use. Still can't see how a simple object for "holding a collection of items" is severely lacking though :confused: As far as im concerned, it has Add/Remove/Count which is exactly what I think it should have. Again, just a different way of dealing with it I guess.
-
Events. These are critical to build ANY form of GUI on top of your domain model and they can be critical within the domain model itself as well. For example, how would you know you needed to write a new item to the database when it is added to the collection in the domain model if you do not get an event when it is added. Sure you can write your own collection class for it, but it is really something I would expect the framework to provide. They did add the BindableList and ObservableCollection (in .NET 3.0). ObservableCollection is as such OK, but: 1) Why do we have two implementations of a list collection with events, and no events on any other collection type? 2) Why are they separate in the first place? Just add the events to the standard collections and be done with it.
lmoelleb wrote:
They did add the BindableList and ObservableCollection (in .NET 3.0). ObservableCollection is as such OK, but:
.NET 2.0 has BindingList<>. I'm using it in an application at the moment, which is the only reason I know that :)
"If you think of yourselves as helpless and ineffectual, it is certain that you will create a despotic government to be your master. The wise despot, therefore, maintains among his subjects a popular sense that they are helpless and ineffectual." - Frank Herbert
-
lmoelleb wrote:
They did add the BindableList and ObservableCollection (in .NET 3.0). ObservableCollection is as such OK, but:
.NET 2.0 has BindingList<>. I'm using it in an application at the moment, which is the only reason I know that :)
"If you think of yourselves as helpless and ineffectual, it is certain that you will create a despotic government to be your master. The wise despot, therefore, maintains among his subjects a popular sense that they are helpless and ineffectual." - Frank Herbert
Yes, that was the one I ment - I just got the name wrong as I haven't touched it since 3.0 was released. The way it forces sorting on a collection simply does not make sense in a lot of cases - as not all collections can be sorted, and those that can might not have a property you can set to determine how it is sorted.