Please see my comment to the question. It is not possible to see the leak, because, by definition, the leak is the property of the whole application (more exactly, the Application Domain,
). If you show the fragment of code, one can either tell "there is no data leaks here", or "there can be a data leak; it depends on the rest of the code".
You code shows the second possibility. Is you add items to the list in your fragment of code repeatedly, you should eventually remove those items repeatedly. Where do you do it? The name
itself is scary. If you add some data somewhere every time you need to show something, this is already wrong.
That's basically all. Just analyze the circulation of your memory and make sure that the memory consumption is not growing with time starting from certain condition, not matter how many times some operations are repeated for any possible operations. If, for example, the user creates more and more resources manually by opening more and more windows until memory is exhausted, this is not a memory leak. The memory leak happens when the user closes all those windows, but the constructed objects do not loose their reachability
]) and thus are never garbage-collected.
Now, I can clearly see that you are not well familiar with collection types and misuse them, as well as the array. Why using
as the element of
type is used to return the key or value while iterating though key-accessed associative containers like
. You could create your own structure.
Why shifting the elements in the array? It's expensive and error-prone. Use
. Learn about usage of collections, there are not too many: http://msdn.microsoft.com/en-us/library/gg145035.aspx