I apologize for my vague reply.
The sequence is like a counter that the dll increments as it creates new objects (here it is curr. The dll takes care of the object destruction). It ranges from 0-1500. This part of the code that I submitted is inside the an event that gets fired from the dll once the curr is available.
The sequence returns the correct value, as I display it the labelCount.
But anyways, I am storing the curr in a local list as I get. If I use list.Count() instead of curr.sequence(), then everything works fine. The problem is solved, but I don't understand why the datagridview has problem with the curr.sequence().
There could be any number of reasons why there's a problem here, but they all come back to the same thing. curr.sequence is in the wrong order - this could be because of threading being used to retrieve values, but it's more likely to do with the item that's sorted on isn't curr.sequence. In other words, the order doesn't match the sort order.
How come there's no such properties as "List|Dictionary.Capacity" - and, does anybody knows if inserting to last slot what's dotnet Collection behavior? Allocate 2xCapacity? In absence of MyDict.Capacity, how can I manipulate this?
Also, when you insert an element if Reference type into collection class, Collection class only stores a "Pointer" or "Reference", not a "Copy"
So, I'm not quite sure why I'd pick a LinkedList over a Dictionary - my guess is, Dictionary's Hash table in the back is still one contiguous block of memory, where as LinkedList is not (but also because it's slots of memory all over the place, access is slower?) But there's no MSDN doc or article which describes this (For example, LinkedList references to payload/elements are stored in usual "array" of reference? If so it too has allocation problem if you keep adding). So really is allocation the only concern?
There is List<T>.Capacity[^]. You can add elements till Count equals Capacity before the internal array gets resized automatically. This[^] might interest you.
There isn't a Capacity for hash-based collections, as it wouldn't be very meaningful; what can be added to a Dictionary, without growing it, depends on the current situation of the buckets and the hash value of the new entries.
[ADDED AFTER OP GOT MODIFIED]
Yes, a collection of reference types stores references. Form.Controls contains the (references to) the Controls of a Form, storing a copy of the Controls would be quite useless as the copy would become stale pretty soon, and changing a property would be irrelevant to the Form.
As far as storage goes, there are three types of collections:
- the regular ones, not hash-based, such as List, SortedList, Set, ...; they internally have a single array.
- the dictionary ones, based on hashing; they use a more complex scheme to improve the search performance.
- the linked-list ones; they store individual items, without using arrays.
Thanks Luc, but for Dictionary, it's internal Hash table still needs to be stored some where right? I presume allocation resembles that of IList - i.e. a dict would allocate a block of contigious memory where hash+reference to actual elements are stored. (i.e. if you keep adding to it, eventually it'd reach "Capacity" specified by Dictionary's constructor)
Further if LinkedList does the same internally, sounds to me real difference between SortedDictionary and LinkedList, don't you think? (LinkedList needs to store an array of references some where and in which case it must have fixed size, unless internally it uses a List<void*>). Forgot to say, both Dictionary and LinkedList supports "ElementAt($INDEX$)", but LinkedList cannot do lookup by Key
LinkedList constructor - you may not specify Capacity (Suspect internal when you add an element SomeClass to the list, LinkedList class would wrap it inside a "Node" object, and node object would have reference to "Next" node. (It's a double linked list behind the scene)[^]
Dictionary - you *can* specify capacity (I suspect therefore when inserting to last slot, reallocation would occur - not sure grow by how much however.)
I suspect therefore when inserting to last slot, reallocation would occur - not sure grow by how much however.
I think dictionaries are typically implemented to grow once a certain percent of capacity has been reached, though "capacity" would be somewhat of a misnomer. So maybe once the array is at least 70% full, then it resizes (read about load factor). Also, dictionaries don't need to resize, as they typically contain collision lists... the resizing is done for performance. As far as how much they would grow, that would probably be some constant multiplier (e.g., by 2x each growth). Some implementations allow you to specify these values (growth factor and resize threshold).
If you want to see how .Net implements the Dictionary class, I recommend using Reflector or ILSpy. You might also consider monitoring your memory usage with very large dictionaries. The MSDN documentation might also contain some info about the constants used.
One of the reasons the implementation details are not in the documentation, is because they can change with new versions of .NET. The implementation details are intentionally hidden from the user so they can be modified/improved if needed, while providing the same external functionality (and general performance characteristics).
If you want to explore the details of the implementation for a particular version of .NET, then Reflector/ILSpy/etc is the way to go. But don't count on those details to be the same in the next release.
I'm not quite sure why I'd pick a LinkedList over a Dictionary
Linked lists and dictionaries are very different data structures. Linked lists contain a list of items. Dictionaries contain a bag of key/value pairs. Linked lists are typically ordered by the order items are inserted. You typically access items in a linked list by nodes (current, next, first). In a dictionary, you access values using a key. Dictionaries may use an array and a bunch of linked lists to store data internally. Linked lists will typically use independent nodes that point to other nodes (i.e., nodes are linked using pointers).
As far as why you would choose one over the other, there are plenty of reasons for that (e.g., random access time for a certain element).
Linked lists are typically ordered by the order items are inserted.
That may be the case, since I'm not sure about "typical" usage. However, linked lists have the special feature that it is easy to insert elements in the middle. Therefore, I'd argue that they aren't ordered by insertion order. An array seems more likely to have elements ordered by order of insertion.
But I'm surprised nobody before you pointed out how different linked lists and dictionaries are in terms of algorithmic efficiency and functionality.
I think I've discovered some kind of bug here:
I have a ListBox control. I fill its content through DataSource property.
First time I set its width equal to ListBox.PreferredSize.Width, no matter what the real preferred width is, it is set to 120.
From the second time use of PreferredSize.Width it works fine: the width is changed according to the content.
lb = new ListBox();
lb.Visible = false;
lb.Width = 50; //initially the width is set to 50this.Controls.Add(lb);
public ShowMyListBox(string data)
lb.DataSource = data;
lb.Width = lb.PreferredSize.Width;
//even though initially the Width is set to 50, lb.PreferredSize.Width returns 120 on the first call//but the following calls returns reliable preferred widths.
lb.Visible = true;
Interesting... Is it a bug? Is there any way to fix it?
Until the control has been fully initialized the preferred size cannot be calculated so the default value is returned. Handling the Load event of the user control and testing PreferredSize in there gives the correct value so you may be better of doing your list box initialization in there.