Develop Reference

Unique dummy object of generic type in C# (to mark deleted slots in array)

I have an array of generic type inside my class.
I am practicing implementing open addressing HashTable (generic version) with different probing - and I want to mark slots of deleted elements, so I can tweak optimisation later (swap items during search and insert into "deleted" slots).
Usually people use some kind of dummy object for this purposes - they assign it to the slot of deleted item and than compare array elements to it during other operations.
But I am not sure if I can do it with generic type in C# - I want to use the HashTable with any Key types - both reference and value. So I don't want to Key to implement any kind of interface.
I saw it used in Java like this:
K DUMMY_DELETED = (K) (new Object());
if(keys[i] == DUMMY_DELETED)
{
...
}
Is there a way to work this out for C# without obliging Key to implement some interface? Or should I use a wrapper for the key-value inside my class?

Generics are implemented differently in Java and C#, so you can't use objects other than the generic type like you can in Java. Some options:
Use Dictionary<TKey, object> and do the cast yourself for non-deleted items
Constrain TValue to an interface that has an IsDeleted property
Define a wrapper class that contains the object, has a pass-through Value property, and has an IsDeleted property. (Similar to Nullable<T>)
Inherit from Dictionary<TKey, KValue> and keep track of deleted "slots" in a separate property.

Datatype of Keys and Values of IReadOnlyDictionary

For IDictionary<TKey, TValue> the Keys and Values properties are of type ICollection<TKey> and ICollection<TValue>.
For IReadonlyDictionary<TKey, TValue> the Keys and Values properties are of type IEnumerable<TKey> and IEnumerable<Value>.
Why aren't the properties of IReadonlyDictionary<TKey, TValue> just the corresponding ReadOnly interfaces, namely IReadOnlyCollection<TKey> and IReadOnlyCollection<TValue>?
One might wonder why both properties aren't of type IEnumerable as you can't alter the dictionary through the two properties but through Add and Remove methods. In fact the ICollection returned by IDictionary.Keys has the IsReadOnly property set, so tried to invoke Add or Remove on the property throws an NotSupportedException with the additional information Mutating a key collection derived from a dictionary is not allowed.
If one anyways can't alter the dictionary through its properties, why aren't the both IReadOnlyCollections?
The IReadOnly interfaces was first introduced in .NET 4.5, so I guess that can't be done without an undesired breakage of backward compatibility.

It puts less of a burden on people implementing a custom IReadonlyDictionary<TKey, TValue> if they did not want to use things that derived from IReadOnlyCollection for their backing stores.
If you are using the built in implementation of ReadOnlyDictionary there is nothing stopping you from casting the interface.
IReadOnlyDictionary<Foo, Bar> baz = GetDictionary();
IEnumerable<Foo> keys = baz.Keys;
IReadOnlyCollection<Foo> keysCollection = keys as IReadOnlyCollection<Foo>;
if(keysCollection != null)
{
//This code will execute for the built in implmentation of `ReadOnlyDictionary<Foo, Bar>`
}

You don't modify either the collection of keys or the collection of values through the Keys and Values properties. You only use those properties to access the keys and values. So it doesn't matter whether or not they are explicitly read-only collections.
The keys and values can only be modified by adding items to the dictionary, which you can't do with an IReadOnlyDictionary.
Also, using an ICollection places an additional restriction on how a particular implementation of IReadOnlyDictionary returns those properties. An IEnumerable<T> can be implemented in many more ways, even by a method using a yield statement. If the returned type is ICollection<T> then the dictionary would be forced to populate something that implements ICollection<T>. It might still do that, but if something implements ICollection<T> then it also implements IEnumerable<T>.
So I'd wonder the other way - why does an IDictionary<T> return ICollection<T> for those properties instead of IEnumerable<T>. (There might be a good reason. But now I'm wondering.)

IEnumerable<T> allows you to take advantage of Linq methods and the whole iterator infrastructure directly, without having to perform a cast.
You can't modify the data in the underlying ReadOnlyDictionary implementation anyway, even through the Key and Value collections. IEnumerable<T> doesn't care whether its underlying implementation is read-only or not.

Sorting IDictionary Generic

I need to know if there is any way of ordering an IDictionary without knowing what type it is exactly ...
For example, I have a method that received an object and within this I have a Dictionary object ... all I know is that it is a Dictionary
so I can do this:
public void MyMethod(PropertyInfo propriedadeParametro, object parameters){
IDictionary dictionary = ((IDictionary) propriedadeParametro.GetValue (parameters, null));
}
but need sort the items of this Dictionary by EnumPersonalizado regardless of what the other Type "something?" has

You can't sort a dictionary. A dictionary, by definition, doesn't have an "order" of the items within it. The items are stored in some mechanism that is beyond your control that is designed to make it as efficient as possible for adding, removing, and searching.
The best that you can do is take all of the items out of the dictionary, put them in some other sort of collection, and then sort that.
As to your particular case, it's not clear to us what the type of the key or the value in the dictionary is, and that would need to be known in order to be able to try to sort the data.

see this question.
Dictionaries by themselves don't have an index order. Consider inheriting from the KeyedCollection class instead. It's a merge of a dictionary and an ordinary list, and it's designed to use a member of your items as the key, and have an index order.

There are plenty of legitimate reasons to want to apply a partial ordering to dictionaries based on key, it isn't a fundamental quality that keys be unordered, only that a given key will yield a given value.
That being said, if you find yourself with a non-generic IDictionary, it can actually be quite troublesome to 'sort' by key without knowledge of the key type. In my specific scenario, I wanted a function which would transform an IDictionary into another IDictionary where the entries could be enumerated by the ordered keys.
IDictionary ToSortedDictionary(IDictionary dictionary) {
return new SortedList(dictionary);
}
This will construct a new dictionary instance, such that traversals (foreach) will visit the entries based on the sort order of the keys.
The oddly named SortedList can be found in System.Collections and orders keys using the ÌComparable interface.

IDictionary is IEnumerable, so you can try to do something like new ArrayList(dictionary).Sort(), but it will try to cast members to IComparable, or you can use a Sort overload which accepts an IComparer object.
Another way is to use a reflection - first you find actual Keys/Values types and then you create a call to generic OrderBy.

C# unique index generic collection

I need a collection that exposes [] operator, contains only unique objects, and are generic. Anyone can help?

Dictionary(Of TKey, TValue) Class represents a collection of keys and values.

HashSet<T>

It depends what you mean by "exposes the [] operator."
If you want to be able to access objects in a unique collection by some arbitrary key, then use a Dictionary<string key, object value>.
If you want to be able to create a list of unique objects which permits access by an ordinal index, in the order in which objects were added, you will need to roll something of your own. I am not aware of any framework class that offers both uniqueness like a HashSet<T> and also allows access to objects in the order in which they were added, like a List<T>. SortedSet<T> almost does it, but does not have indexer access - so while it does maintain order, it does not allow access using that order except through enumeration. You could use Linq extension method ElementAt to access the element at a particular ordinal index, but performance would be very bad since this method works by iteration.
You could use also Dictionary<int key, object value> but you will still have to maintain the index yourself, and if anything is ever removed, you'd have a hole in your list. This would be a good solution if you never had to remove elements.
To have both uniqueness and access by index, and also be able to remove elements, you need a combination of a hash table and an ordered list. I created such a class recently. I don't think this is necessarily the most efficient implementation since it does its work by keeping two copies of the lists (one as a List<T> and one as a HashSet<T>).
In my situation, I valued speed over storage efficiency, since the amount of data wasn't large. This class offers the speed of a List<T> for indexed access and the speed of a HashTable<T> for element access (e.g. ensuring uniqueness when adding) at the expense of twice the storage requirements.
An alternative would be to use just a List<T> as your basis, and verify uniqueness before any add/insert operation. This would be more memory efficient, but much slower for add/insert operations because it doesn't take advantage of a hash table.
Here's the class I used.
http://snipt.org/xlRl

The HashSet class should do the trick. See HashSet(Of T) for more information. If you need them to maintain a sorted order, the SortedSet should do the trick. See SortedSet(Of T) for more information about that class.

If you're looking to store unique objects (entities, for example) while exposing a [], then you want to use the KeyedCollection class.
MSDN KeyedCollection
using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
// This class represents a very simple keyed list of OrderItems,
// inheriting most of its behavior from the KeyedCollection and
// Collection classes. The immediate base class is the constructed
// type KeyedCollection<int, OrderItem>. When you inherit
// from KeyedCollection, the second generic type argument is the
// type that you want to store in the collection -- in this case
// OrderItem. The first type argument is the type that you want
// to use as a key. Its values must be calculated from OrderItem;
// in this case it is the int field PartNumber, so SimpleOrder
// inherits KeyedCollection<int, OrderItem>.
//
public class SimpleOrder : KeyedCollection<int, OrderItem>
{
// The parameterless constructor of the base class creates a
// KeyedCollection with an internal dictionary. For this code
// example, no other constructors are exposed.
//
public SimpleOrder() : base() {}
// This is the only method that absolutely must be overridden,
// because without it the KeyedCollection cannot extract the
// keys from the items. The input parameter type is the
// second generic type argument, in this case OrderItem, and
// the return value type is the first generic type argument,
// in this case int.
//
protected override int GetKeyForItem(OrderItem item)
{
// In this example, the key is the part number.
return item.PartNumber;
}
}

What is the difference between LINQ ToDictionary and ToLookup

What is the difference between LINQ ToDictionary and ToLookup? They seem to do the same thing.

A dictionary is a 1:1 map (each key is mapped to a single value), and a dictionary is mutable (editable) after the fact.
A lookup is a 1:many map (multi-map; each key is mapped to an IEnumerable<> of the values with that key), and there is no mutate on the ILookup<,> interface.
As a side note, you can query a lookup (via the indexer) on a key that doesn't exist, and you'll get an empty sequence. Do the same with a dictionary and you'll get an exception.
So: how many records share each key?
An overly simplified way of looking at it is that a Lookup<TKey,TValue> is roughly comparable to a Dictionary<TKey,IEnumerable<TValue>>

ToDictionary is <TKey, TValue> while ToLookup<TKey, T1, T2, T3, ...> is is similar to IGrouping but enumeration stays in memory.