What type of collection do I need?

Unity Engine
1

Unsure as to what type of collection I should be using.

My requirements
The collection will be constantly changing in size, adding to and removing objects.
Order does not matter
Length DOES matter, will have maximum length (3 or4) and must be able to retrieve length.

2

Sounds mostly like a straightforward List<>. I don’t think List<> can enforce a maximum size, but you can do that in your code. After all, what do you want to happen if the your application attempts to exceed the maximum size? Although, if you set the capacity property of your list to maximum size, than you can keep adding and removing items without your list allocating memory, as long as you don’t attempt to go over the maximum.

If you really want to, it would probably be pretty easy to implement your own collection, using an array (since your requirements are pretty simple).

1 Like
3

As an alternative to List, your requirements sound almost like a ‘HashSet’ as well:

A HashSet is an unordered set of objects with no duplicates.

It has length.
It allows adding and removing.
Order is not conserved (you said no order necessary)

List will allow duplicates.

You didn’t say if you wanted to allow duplicates or not. But if you don’t want duplicates, with List you’ll have to continually check ‘Contains’ at first.

HashSet is also an O(1) collection for finding entries (Contains, Remove). Though technically speaking at sizes as low as 3 or 4 in length the cost of hashing the object will make both List and HashSet perform similarly. You’ll only notice that O(1) gains when the collection grows larger.




Personally I use HashSet’s a lot. For example I use them when I want to keep track of what is in/out of some situation.

Like for example if I have a Collider trigger and on enter I want to store that something is in the collider, and on exit I want to remove it from that store. Thusly giving me an easy access to what is currently intersecting the collider. I use a HashSet. This is especially useful since an entity might contain multiple colliders that trigger onenter repeatedly for the same entity. The non-duplicates quickly deals with that.

Like here:

Here’s another:

This watches for if multiple t_'s are triggered, and triggers if all of them are. So like it can monitor multiple t_OnTriggerOccupied and signal if all of them are signaling.

This could be useful for those puzzles where each switch needs to be stepped on at the same time. You can monitor all N switches for being occupied and only signal when they all do. So then you can do a push puzzle to place boxes on them, or a multi-player puzzle where every player has to stand on it.

4

The usual thing is to start with a List. Those are arrays with useful functions built-in. Then only use some other container if there’s a problem with speed in a large list:

o ArrayList is old Java-style. Never use it for anything.

o If you insert/remove lots of times not to the back, LinkedLists are faster.

o If the size is small, like 20 or less, it won’t even matter. Use a List, since thinking about using anything else is a distraction.

o Hashes/Sets are for when if(A[“hammer”]!=null) is all you will ever need to do. When your container represents a set in math.

o If you’re using a system who’s API takes and returns lots of arrays, such as Unity, and your container interacts with them, consider using an array.

1 Like
5

I haven’t found a similar pic for C#, but check out this collection cheat sheet for Java:

It’s pretty much the same classes in C#, except Map is Dictionary.

EDIT: Also, you’ve got Queue and Stack for First-In-First-Out(FIFO) and Last-In-First-Out(LIFO).

2 Likes
6

So funny. That’s from StackExchange Java under “What collection should I use”. It’s copied from some guy’s blog page, which is now a 404. Of the three comments, one points out LinkedList is missing (which is pretty important). The other two are asking some technical Q and the guy responding “Beats me. The arrows to get to those 2 things have different words, is all I know”.

The other replies (to the Q, not the picture) explain them in words. One has the correct answer: read any book about how basic data structures are made. If you know how a LinkedHashMap works, you’ll know when to use it (it’s a LinkedList and a Dictionary rammed together).

But the super funny part is we used to use flow charts in the '70, back when all we had was goto’s. We quit right after that. Most of the flow charts you see now are jokes. I was thinking this was, and I’m still not sure.

7

Just put all the flowcharts in a List and that’ll solve the problem.

1 Like
8

Use a List but assign it to an ICollection property. You can change the type later if you find you need to.

1 Like
9

Not possible. I still need some concrete container type to create it, and I’m stuck on the first diamond: does a flow chart contain key/value pairs, or values only?

10

I believe eisenpony was responding to OP, and eisenpony did state a concrete container type: List.

1 Like
11

Right 
 I’m confused. Did you mean to “Reply” to lordofduct’s message?
Or 
 I guess both?..

Anyways, List is the way forward for the OP. Then, maybe, learn more about the data structures available in C#.