|
For the most part the way you interact with a List<T> and an ArrayList are the same. They provide very similar functionality to the calling code.
Specifically, List<Object> is defining a generic list of type Object so from a data type point of view it is the same as ArrayList since ArrayList can only contain objects.
In general, I think it is preferable to use the generics, particularly if you are working with strong data types (things other than objects) as you are able to get better performance from the generics because you no longer have most (if not all) of the boxing/unboxing operations that need to be performed. That being said, by creating a List<Object>, you probably aren't really gaining a whole lot over an ArrayList.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
List<object> and ArrayList are very similar, but there are some implementation differences:
The List<object> methods are not virtual and the List enumerator is a value type, whereas ArrayList requires virtual method calls and needs a heap allocation for the enumerator. So List<object> is a tiny bit faster than ArrayList.
I'd always use List<T>, even if you don't avoid any boxing and don't get any type safety in the List<object> case.
|
|
|
|
|
If you're not able to appreciate the difference, use the ArrayList. The other way passes through led mike's suggestion.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
The generic List class has practically replaced the ArrayList class. Don't use the ArrayList class any more.
For the rare case where you actually need a list of object references, use List<object> instead of ArrayList. That way it's obvious that you needed exactly that kind of list, and that you are not just using ArrayList because you don't know any better.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
I am trying to create a table in an Access database
I have verified all of my SQL commands work in SQL Server so I'm figuring that i have a formatting for C# issue i am over looking or doing something wrong via the OLDDB driver
here is my code
String connect = "Provider=Microsoft.JET.OLEDB.4.0;data source=.\\Test.mdb";
OleDbConnection con = new OleDbConnection(connect);
con.Open();
OleDbCommand cmd = con.CreateCommand();
cmd.CommandText = "Create Table GroupPolicy(GUID char(50) NOT NULL Unique, GPONAME char(50), Domain Char(50), Created datetime, Modified datetime, Status char(10))";
try
{
cmd.ExecuteNonQuery();
}
catch (Exception ex)
{
MessageBox.Show(ex.ToString());
}
con.Close();
the exception is telling me there is a syntax error
Thanks
|
|
|
|
|
Planker wrote: I am trying to create a table in an Access database
I have verified all of my SQL commands work in SQL Server
Access SQL is NOT EQUAL to SQL Server.
Therefore your test is invalid. Try testing your SQL in the Database you are targeting. That is always the best approach.
Good luck
led mike
|
|
|
|
|
Thanks, I am trying to figure out what the correct commands are, I see examples all over the internet using the SQL create table command on a Access using OLEDB, but everything i try does not work.
modified on Wednesday, October 8, 2008 2:02 PM
|
|
|
|
|
Planker wrote: Thanks, I am trying to figure out what the correct commands are
Sure, but wouldn't something like the documentation[^] be a good place to start?
led mike
|
|
|
|
|
Thanks for pointing me in the right direction, I am making some progress now.
|
|
|
|
|
Planker wrote: I am making some progress now.
Cool ![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif)
led mike
|
|
|
|
|
Hi!
I am currently working on a project, where I have to make an API assembly to our main functionality.
The issue is that i'm in fact making two assemblies one, which is comon and one which intented as the assembly, which should expose the API functions to our customers. If I try to use the API assembly my common assembly is also required for the client program which is using my API assembly in order to compile, even though I have no direct referances to the common assembly are thiere any way that I can get around this so that I do not have to referance the common assembly in by client program ?
Many thanks in advance.
Kind regards
Jakob
|
|
|
|
|
Ummmm, what?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Well I will try to clarify. I have two assemblies, which makes up my api and I will like to keep that way and I only want to expose one of the assemblies to my custormers. So that they in principle only have worry about one of the assemblies and referance only one assembly in there client programs.
I hope this clarifies the problem.
Kind regards
Jakob
|
|
|
|
|
If there are no dependencies between them why not just compile them as two independant dll's?
If there are interdependencies then just compile them to a single dll.
Or have I missed the point entirely?
Bob
Ashfield Consultants Ltd
|
|
|
|
|
Instead of doing two assemblies, make one, and make the classes in the non-public one private within the public one.
Any public object in an assembly will be exposed. See if there's an .Net attribute available that marks a class as not exposed or something like that. If not, you'll have to follow my first suggestion.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Yes you can. Although I would not recommend it you can embed the assembly as a resource in another assembly and then return it from an Assembly Resolve event such as
appDomain.AssemblyResolve += new ResolveEventHandler(OnAssemblyResolve);
In the event call your assembly and ask for the other assembly as a binary file and viola.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego.
|
|
|
|
|
No, but you can have a class inside a class, is that what you mean?
|
|
|
|
|
|
Hi!
I just stumbled over an unexpected behaviour when trying to serialize a derived class using a BinaryFormatter, I guess the best is to show in code:
Animal a = new Animal();
Dog d = new Dog();
Animal dogAsAnimal = d as Animal;
BinaryFormatter bf = new BinaryFormatter();
bf.Serialize(serializationStream, a);
bf.Serialize(serializationStream, dogAsAnimal); I can't really understand why the last line is trying to serialize the object as Dog instead of Animal - is there any way to keep BinaryFormatter from doing this (short of adding a copy constructor to Animal and actually creating a new object)?
Thanks in advance!
Regards,
mav
--
Black holes are the places where God divided by 0...
|
|
|
|
|
bf.Serialize(serializationStream, (Animal) d); ?
|
|
|
|
|
It doesn't matter whether I use as or an explicit cast.
In the real code I had a method ToFile(Animal a, string path) and it also showed the effect.
The debugger does show that it's an Animal reference in every case.
Regards,
mav
--
Black holes are the places where God divided by 0...
|
|
|
|
|
The derived class also has to be serializable.
I think you'll also find that only protected and public vars will be serialized from the base class, but I'm just guessing at that.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
But that's something I explicitely do not need/want. Of course I could flag Dog as Serializable, too, but then the object is serialized as Dog, not as Animal.
The other side of the line (where the object is supposed to be deserialized) doesn't know about Dogs, it only knows about Animals (i.e. there's only the assembly defining Animal available, not the one defining Dog, so trying to deserialize this object will throw a TypeLoadException).
Regards,
mav
--
Black holes are the places where God divided by 0...
|
|
|
|
|
Well, it appears from your code sample as if you really want to serialize the Dog object. I don't understand why you wouldn't want to do that, since you can Deserialize it and cast it back to animal if that's what you really need. Why in the world would the deserialize code not know about the dog object. It looks from here as if your design needs to be re-engineered.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
The simplest explanation for what mav's doing is that animal is owned by a different team and are either unwilling or unable to modify the object to contain additional functionality that is needed in mav's part of the project. For every part of the app except serialization having dog inherit from animal makes a more natural design than having dog have an animal member.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots.
-- Robert Royall
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
