Question Beginner array question

[SeaBee]

I'm struggling to determine which type of array I should use.
Array, SortedArray, ArrayList, IList. They all have pros and cons but none of them seem to be perfect for what I need.

I have an array of strings and I need to be able to sort it alphabetically, remove any duplicates or strings that are numerical only, and search it.
I can determine if a string only has numbers in it so that is not an issue.
I just need advice on which type of array to use and how best to sort it, search it and remove unwanted elements.

Thanks

 

[JohnH]

Use a List<string>. List<T> Class (System.Collections.Generic)
It is convenient for removing elements, and supports sorting.

Regular array requires much code to remove an element. You probably mean SortedList, that is more like a dictionary. ArrayList is an old class that is like a List<object>. IList is an interface, used to implement collection types.

 

[NoUserHere]

You're approaching this wrong. Firstly, you want to prevent items being added that do not belong there. Right? Don't add them and check if it should belong there after. Prevention is best! If you show what code you've developed with so far, maybe we can give you some more practical pointers, and recommend some alterations.

Secondly, why are you using an array?

Thirdly, if you want to acquire a collection of items, then you should use an appropriate collection for whatever object type you wish to store inside said collection. You can call on some Linq to do your sorting for you.

 

[SeaBee]

What I'm trying to do is create a list of directories, subdirectories and files. Then store a list of every individual words in the file name/path in an array (of sorts) so that each file has a list of 'tags' that can be searched for based on the file path.
I'll give Lists a go but since you asked for my code, I've included it below. So if anyone knows of a better way to do what I'm trying to do, then I'm all ears.

Thanks

class library
    {
        string[] dirs;
        string[] files;
        ArrayList tags = new ArrayList();


        public library(string path)
        {
            this.dirs = Directory.GetDirectories(path, "*", SearchOption.AllDirectories);
            this.files = Directory.GetFiles(path, "*", SearchOption.AllDirectories);
            GetTags();
        }

        public int GetDirCount() { return dirs.Length; }

        public int GetFileCount() { return files.Length; }

        public int GetTagCount() { return tags.Count; }
    

        public void ShowTags()
        {
            Console.WriteLine(tags[0]);
            foreach(string tag in tags)
            {
               Console.WriteLine(tag);
            }
        }


        public void GetTags()
        {
            foreach(string item in dirs)
            {
                char[] separator = {' ', '\\', '/', '-', '_'};
                string[] tag = item.Split(separator, StringSplitOptions.RemoveEmptyEntries);
                foreach(string t in tag)
                {
                    tags.Add(t);
                }
                
            }
        }

        public void RemoveDigitsOnly()
        {
            foreach(var tag in tags)
            {
                if (IsDigitsOnly(tag.ToString()))
                {
                    //Remove from Array
                }
            }
        }


        public bool IsDigitsOnly(string str)
        {
            foreach (char c in str)
            {
                if (c < '0' || c > '9')
                    return false;
            }
            return true;
        }
    }

 

[jmcilhinney]

I'm struggling to determine which type of array I should use.
Array, SortedArray, ArrayList, IList. They all have pros and cons but none of them seem to be perfect for what I need.

Most of those aren't arrays. Only arrays are arrays. You should use an array if you know how many elements there will be when you create it and that number will not change. If you don't know how many items there will be and/or you want to be able to add and remove items then you should probably use a List<T>, where T is the type of the items you want to store. Those are the only two types of simple lists most people should consider. Both can be sorted in place and searched fairly easily.

There's no such thing as a SortedArray, the ArrayList class was the forerunner to the List<T> class and should not be used any more, while IList is an interface that all list types implement, including arrays, the ArrayList class and the List<T> class.

 

[NoUserHere]

There's no such thing as a SortedArray

Almost arguing semantics here, but that's not to say you can't sort an array. lol Array.Sort Method (System)

 

[jmcilhinney]

Almost arguing semantics here, but that's not to say you can't sort an array. lol Array.Sort Method (System)

True. I specifically meant that there is no specific type named SortedArray. As JohnH suggested, maybe the intent was to refer to the SortedList class instead, but that is obsolete now too, with a generic version now available. As I said:

Both [arrays and the List<T> class] can be sorted in place and searched fairly easily.

 

[NoUserHere]

I know what you meant John. I was kinda winding you up a little since I know you love to argue semantics on trivial subjects.

Don't suppose anyone has a date when the Sorted list became obsolete?

 

[Skydiver]

If you first adding everything into an List, or List<T> once at the cost of O(2*n) memory. Before you say that lists are only supposed to be O( n ) memory, keep reading. Although textbooks say that adding to a list is O(1) because they assume linked lists, in the .NET Framework, lists are actually implemented as arrays because of better memory cache coherency performance. It keeps adding items to the end of the array. If the array is full, a new array is allocated, and the old items are copied over into the new array at the cost of O( n ). If that were implemented naively, then the cost of inserting n items into a .NET Framework list would be O(n^2). Fortunately, the MS developers are not naive, and they actually double the size of the array each time it fills to minimize the cost of the copy, so that the insertion cost would be more like O(n log n). Unfortunately, that brings you back to O(2 * n) for memory. The sorting cost is O(n log n), but don't forget to also account for the cost it took to add the times into the list.

The SortedList or SortedList<TKey, TValue> gives you O(log n) + O(n/2) + O(n^2) complexity insertion time. The O(log n) is to find the insertion point within the array using binary search, and the the O(n/2) is the cost of moving items around to make room for the new key and value. Like the list above, the arrays need to grow from time to time, so there is also the O(n^2) cost to move items around. Since they sorted lists use one array is for the keys, and another for the values, the memory cost of would be O(2*n). But since you now have two arrays to move around the previous insertion complexity doubles for the memory moves/reallocations to give us O(log n) + O( n ) + O(4n^2)

So to summarize I think these are the costs:

	Memory	CPU
Insert into SortedList<TKey,TValue>	O(2*n)	O(log n) + O( n ) + O(4n^2)
Insert into List<T>, then Sort()	O(2*n)	O(n log n) + O(n log n)

Look like adding to a list first and then sorting is better.

 

[JohnH]

Don't suppose anyone has a date when the Sorted list became obsolete?

Better replacements where introduced with generics in .Net Framework 2.0 in 2005. This is linked to in documentation Remarks for the non-generic collections: dotnet/platform-compat

 

[NoUserHere]

Thanks John, turns out to be 5 years back actually according to microsoft/referencesource

 

[JohnH]

It's a FEATURE_CORECLR condition. The date is when .NET Core 1.0 was announced on November 12, 2014. I guess that was the start of open source .Net Core. It is not marked with Obsolete attribute for .Net Framework that I can see: What's Obsolete in the .NET Framework class library

 

[NoUserHere]

That's correct. From what I understood too, its only .Net Core

 

[jmcilhinney]

I know what you meant John. I was kinda winding you up a little since I know you love to argue semantics on trivial subjects.

I take umbrage with the implication that any subject I argue on is trivial.