public static Dictionary<int, string> dic = new Dictionary<int, string>() {
{1,"anystring1"},
{2,"anystring2"}};
I need to use this
string str= dic[1]; // it is possible
int a=dic["anystring1"]; // My dream is it
Use another Dictionary<> and use it in reverse order of key/value.
I'm a bit late on this one, but LINQ is your friend here:
MyDict.FirstOrDefault(pair => pair.Value == "the value you want").Key;
Allows you to do what you want.
I wish this was in the System library, but it's pretty easy to roll your own.
Below, I'll provide the skeleton of writing such a class, whose usage looks like:
var twoWayDict = new TwoWayDict<string, int>();
twoWayDict["zero"] = 0;
// twoWayDict["zero"] == 0
// twoWayDict.Reverse[0] == "zero"
twoWayDict.Reverse[1] = "one";
// twoWayDict["one"] == 1
// twoWayDict.Reverse[1] == "one"
Keep in mind, one gotcha for a two way dictionary is that you should expect all input to be tightly coupled. In other words, if you re-use a key OR a value, you will erase the data previous linked with either:
twoWayDict["zero"] = 0;
// Then later...
twoWayDict.Reverse[0] = "ZERO";
// Now twoWayDict["ZERO"] == 0
// Later still...
// Exception: Key not found! "zero" was dropped when you re-used value 0
Console.WriteLine(twoWayDict["zero"]);
Finally, here's some sample code. It's minimal - it should act as a foundation for anyone who wants to flesh out their own version. Note that I implement a wrapper class so I can provide a "Reverse" property without directly exposing the internal dictionary.
// Generics note: K indicates "key" type and V indicates "value" type
using System.Collections.Generic;
namespace YourNamespaceHere.Collections
{
public class TwoWayDict<K, V>
{
private Dictionary<K, V> _dictKV;
private Dictionary<V, K> _dictVK;
private ReverseDict _reverseDict;
public TwoWayDict()
{
_dictKV = new Dictionary<K, V>();
_dictVK = new Dictionary<V, K>();
_reverseDict = new ReverseDict(this);
}
public ReverseDict Reverse
{
get { return _reverseDict; }
}
// TwoWayDict[key] -> value
public V this[K key]
{
get { return _dictKV[key]; }
set
{
// Remove any existing key/value pair
Remove(key);
_dictKV[key] = value;
_dictVK[value] = key;
}
}
public void Remove(K key)
{
if (_dictKV.ContainsKey(key))
{
_dictVK.Remove(_dictKV[key]);
_dictKV.Remove(key);
}
}
// Wrapper that allows TwoWayDict to expose a convenient
// 'Reverse' property.
public class ReverseDict
{
private TwoWayDict<K, V> _parent;
public ReverseDict(TwoWayDict<K, V> parent)
{
_parent = parent;
}
public K this[V reverseKey]
{
get { return _parent._dictVK[reverseKey]; }
set { _parent[value] = reverseKey; }
}
public void Remove(V value)
{
if (_parent._dictVK.ContainsKey(value))
{
_parent.Remove(_parent._dictVK[value]);
}
}
}
}
}
That is not what a dictionary is meant to do. Can you think of a definition and instantly find the matching word in your favorite dictionary in O(1) time? If you want a class with that type of functionality (a bidirectional dictionary) you will have to build it yourself (or Google for one of many implementations on the Internet).
I actually use a class that combines an ArrayList with a Dictionary so that I can look up child nodes based on name or order added, and maintain the original order of the objects as they were added.
Objects are added to the ArrayList first, then the index of that object in the ArrayList is added to the dictionary using the desired key.
This allows me to access either by key or position, in a very optimal way, while maintaining the order of the objects as they were added.
Gotcha areas to watch for are adding another object using an existing key, which will orphan the original object and removing any element from the vector which will cause the indices in the Dictionary to become corrupted, pointing to the wrong values.
Just thought I would share my two cents worth - hope it helps someone.
Related
In general terms, a program I'm making involves storing a small number of entries (probably less than 30 at any given time) which can be categorized. I want to allow these entries to be seen but not altered from outside the class using them. I made a class called Entry which could be modified and another called ReadOnlyEntry which is a wrapper for an Entry object. The easiest way to organize these Entry objects it seems is to create a List<List<Entry>>, where each List<Entry> is a category. But then exposing that data in a readonly way became messy and complicated. I realized I would have to have one object of each of the following types:
List<List<Entry>> data;
List<List<ReadOnlyEntry>> // Where each ReadOnlyEntry is a wrapper for the Entry in the same list and at the same index as its Entry object.
List<IReadOnlyCollection<ReadOnlyEntry>> // Where each IReadOnlyCollection is a wrapper for the List<ReadOnlyEntry> at the same index in data.
IReadOnlyCollection<IReadOnlyCollection<ReadOnlyList>> readOnlyList // Which is a wrapper for the first item I listed.
The last item in the list would be exposed as public. The first lets me change entries, the second lets me add or delete entries, and the third lets me add or delete categories. I would have to keep these wrappers accurate whenever the data changes. This seems convoluted to me, so I'm wondering if there's a blatantly better way to handle this.
Edit 1:
To clarify, I know how to use List.asReadOnly(), and the stuff I proposed doing above will solve my problem. I'm just interested in hearing a better solution. Let me give you some code.
class Database
{
// Everything I described above takes place here.
// The data will be readable by this property:
public IReadOnlyCollection<IReadOnlyCollection<ReadOnlyList>> Data
{
get
{
return readOnlyList;
}
}
// These methods will be used to modify the data.
public void AddEntry(stuff);
public void DeleteEntry(index);
public void MoveEntry(to another category);
public void AddCategory(stuff);
public void DeleteCategory(index);
}
You can use List<T>.AsReadOnly() to return ReadOnlyCollection<T>.
Also, you're torturing the List<T> class storing the data the way you are. Build your own hierarchy of classes which store your individual lists.
.NET collections should support covariance, but they don't support it themselves (instead some interfaces support covariance https://msdn.microsoft.com/ru-ru/library/dd233059.aspx). Covariance means List<Conctrete> behaves like subclass of List<Base> if Concrete is subclass of Base. You can use interfaces covariation or just use casting like this:
using System.Collections.Generic;
namespace MyApp
{
interface IEntry
{
}
class Entry : IEntry
{
}
class Program
{
private List<List<Entry>> _matrix = null;
public List<List<IEntry>> MatrixWithROElements
{
get
{
return _matrix.ConvertAll(row => row.ConvertAll(item => item as IEntry));
}
}
public IReadOnlyList<List<IEntry>> MatrixWithRONumberOfRows
{
get
{
return _matrix.ConvertAll(row => row.ConvertAll(item => item as IEntry));
}
}
public List<IReadOnlyList<IEntry>> MatrixWithRONumberOfColumns
{
get
{
return _matrix.ConvertAll(row => row.ConvertAll(item => item as IEntry) as IReadOnlyList<IEntry>);
}
}
public IReadOnlyList<IReadOnlyList<IEntry>> MatrixWithRONumberOfRowsAndColumns
{
get
{
return _matrix.ConvertAll(row => row.ConvertAll(item => item as IEntry));
}
}
public void Main(string[] args)
{
}
}
}
Thanks to Matthew Watson for pointing on errors in my previous answer version.
You could make an interface for Entry which contains only getters; you would expose elements via this interface to provide read-only access:
public interface IEntry
{
int Value { get; }
}
The writable implementation would be simply:
public sealed class Entry : IEntry
{
public int Value { get; set; }
}
Now you can take advantage of the fact that you can return a List<List<Entry>> as a IReadOnlyCollection<IReadOnlyCollection<IEntry>> without having to do any extra work:
public sealed class Database
{
private readonly List<List<Entry>> _list = new List<List<Entry>>();
public Database()
{
// Create your list of lists.
List<Entry> innerList = new List<Entry>
{
new Entry {Value = 1},
new Entry {Value = 2}
};
_list.Add(innerList);
}
public IReadOnlyCollection<IReadOnlyCollection<IEntry>> Data => _list;
}
Note how simple the implementation of the Data property is.
If you need to add new properties to IEntry you would also have to add them to Entry, but you wouldn't need to change the Database class.
If you're using C#5 or earlier, Data would look like this:
public IReadOnlyCollection<IReadOnlyCollection<IEntry>> Data
{
get { return _list; }
}
I have a ComboBox filled with mixed items of two different types. The types are either
KeyValuePair<Int32, FontFamily>
or
KeyValuePair<Int32, String>
Now there are occasions where I am only interested in the Key of the selected item, which is always an Int32.
What would be the easiest way to access the Key of the selcted item? I am thinking of something like
Int32 key = ((KeyValuepair<Int32, object/T/var/IdontCare>)combobox.SelectedItem).Key;
but that doesn´t work.
So all I have is
Int32 key;
if(combobox.SelectedItem.GetType().Equals(typeof(KeyValuePair<Int32, FontFamily)))
{
key = ((KeyValuePair<Int32, FontFamily)combobox.SelectedItem).Key;
}
else if(combobox.SelectedItem.GetType().Equals(typeof(KeyValuePair<Int32, String)))
{
key = ((KeyValuePair<Int32, String)combobox.SelectedItem).Key;
}
which works, but I wonder if there is a more elegant way?
Casting to dynamic (poor man's reflection) can do the trick
var key = (int) ((dynamic) comboxbox.SelectedItem).Key);
You certainly don't need to use GetType(). You could use:
int key;
var item = combobox.SelectedItem;
if (item is KeyValuePair<int, FontFamily>)
{
key = ((KeyValuePair<int, FontFamily>) item).Key;
}
else if (item is KeyValuePair<int, string>)
{
key = ((KeyValuePair<int, string>) item).Key;
}
I don't think there's really a better way without using reflection or dynamic typing, assuming you can't change the type of the selected items to your own equivalent to KeyValuePair with some non-generic base type or interface.
I guess it's bound in WPF, in that case I would suggest to not use KeyValuePair<TKey,TValue> but instead an own VM class. E.g.
class MyComboItem
{
private String _stringValue;
private FontFamiliy _fontFamilyValue;
public Int32 Key {get;set;}
public object Value => (_fontFamilyValue!=null)?_fontFamilyValue:_stringValue;
}
or you could have an interface like
interface IMyComboItem
{
Int32 Key {get;}
object Value {get;}
}
and implement two VM classes that implement it storing the proper value type.
With proper constructors and so on. Casting as you want achieve isn't possible with generics, and your solution case isn't elegant.
You can create your own class hierarchy like this
public interface IComboBoxItem
{
public int Key { get; }
}
public class ComboBoxItem<T> : IComboBoxItem
{
public T Value { get; set; }
public int Key { get; set; }
}
and your cast will look like this:
key = ((IComboBoxItem)combobox.SelectedItem).Key;
Building on Rich's answer, I used Dynamic successfully. I knew the dictionary type I was binding to (and realistically could have used the dictionary itself, since that was still referenced in my form), but I wanted to create a method to search by the displayname. This will eventually check if the binding source is a datatable too, but for now, this worked well for a <string,?> dictionary.
private void SetComboBoxSelection(ComboBox cmb, string ItemText)
{
if (cmb.DisplayMember.ToLower() == "key" && cmb.ValueMember.ToLower() == "value")
{
foreach (dynamic item in cmb.Items)
if (item.Key == ItemText)
cmb.SelectedItem = item.Value;
}
}
I basically need a data structure that works just like a Set, but that not only maintains insert order as let's me get them later by a get(index) method.
What is the data structure best suited to achieve this? I wouldn't have a problem in having to implement one, if needed. In the worse case I could just use both an ArrayList and a HashSet, but I'm wondering whether there is a specialized data structure up to the task.
Performance is paramount (otherwise I could just do a O(n) search over a regular list!) and I'm not that worried about spatial complexity.
How about OrderedDictionary ?
Represents a collection of key/value pairs that are accessible by the
key or index.
http://msdn.microsoft.com/en-us/library/system.collections.specialized.ordereddictionary.aspx
Something like this? Edit: As Jiddo noted, this structure can't remove elements efficiently. ArrayList + Set is simpler if an efficient remove is not required, so this structure isn't actually good for much.
import java.util.*;
public class ArraySet<T> {
private final Map<Integer, T> indexToElem;
private final Map<T, Integer> elemToIndex;
public ArraySet() {
indexToElem = new HashMap<Integer, T>();
elemToIndex = new HashMap<T, Integer>();
}
public T get(int index) {
if (index < 0 || index >= size())
throw new IndexOutOfBoundsException();
return indexToElem.get(index);
}
public void add(T elem) {
if (!contains(elem)) {
int index = indexToElem.size();
indexToElem.put(index, elem);
elemToIndex.put(elem, index);
}
}
// Doesn't work; see comment.
/*public void remove(T elem) {
int index = elemToIndex.get(elem);
indexToElem.remove(index);
elemToIndex.remove(elem);
}*/
public boolean contains(T elem) {
return elemToIndex.containsKey(elem);
}
public int size() {
return indexToElem.size();
}
}
Are you open to using existing code? Apache Commons has a ListOrderedSet class that seems to fit all your requirements. Worst come to worse you could study the source code and implement in C#.
In C# I find indexed properties extremely useful. For example:
var myObj = new MyClass();
myObj[42] = "hello";
Console.WriteLine(myObj[42]);
However as far as I know there is no syntactic sugar to support fields that themselves support indexing (please correct me if I am wrong). For example:
var myObj = new MyClass();
myObj.field[42] = "hello";
Console.WriteLine(myObj.field[42]);
The reason I need this is that I am already using the index property on my class, but I have GetNumX(), GetX(), and SetX() functions as follows:
public int NumTargetSlots {
get { return _Maker.NumRefs; }
}
public ReferenceTarget GetTarget(int n) {
return ReferenceTarget.Create(_Maker.GetReference(n));
}
public void SetTarget(int n, ReferenceTarget rt) {
_Maker.ReplaceReference(n, rt._Target, true);
}
As you can probably see exposing these as one indexable field property would make more sense. I could write a custom class to achieve this every time I want the syntactic sugar but all of the boilerplate code just seem unnecessary.
So I wrote a custom class to encapsulate the boilerplate and to make it easy to create properties that can be indexed . This way I can add a new property as follows:
public IndexedProperty<ReferenceTarget> TargetArray {
get {
return new IndexedProperty<int, ReferenceTarget>(
(int n) => GetTarget(n),
(int n, ReferenceTarget rt) => SetTarget(n, rt));
}
}
The code for this new IndexedProperty class looks like:
public class IndexedProperty<IndexT, ValueT>
{
Action<IndexT, ValueT> setAction;
Func<IndexT, ValueT> getFunc;
public IndexedProperty(Func<IndexT, ValueT> getFunc, Action<IndexT, ValueT> setAction)
{
this.getFunc = getFunc;
this.setAction = setAction;
}
public ValueT this[IndexT i]
{
get {
return getFunc(i);
}
set {
setAction(i, value);
}
}
}
So my question is: is there a better way to do all of this?
Well to be specific, is there a more idiomatic way in C# to create an indexable field property, and if not how could I improve my IndexedProperty class?
EDIT: After further research, Jon Skeet calls this a "named indexer".
EDIT FOR 2022: This continues to get votes, but it probably isn't something I would use today primarily because it does push garbage collection in a way that would not be ideal at scale, if the property was being hit a lot. I remember this being a complicated topic, and I do not want to go deep on researching it right now, but I wonder if indexers could solve this problem today. See: https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/indexers/
I found your idea useful, so I extended it. This may not technically be a proper answer since I'm not sure it squarely answers your question, but I thought it might be useful to people who came here looking for property indexers.
First, I needed to be able to support get-only and set-only properties, so I made a slight variation of your code for these scenarios:
Get and Set (very minor changes):
public class IndexedProperty<TIndex, TValue>
{
readonly Action<TIndex, TValue> SetAction;
readonly Func<TIndex, TValue> GetFunc;
public IndexedProperty(Func<TIndex, TValue> getFunc, Action<TIndex, TValue> setAction)
{
this.GetFunc = getFunc;
this.SetAction = setAction;
}
public TValue this[TIndex i]
{
get
{
return GetFunc(i);
}
set
{
SetAction(i, value);
}
}
}
Get Only:
public class ReadOnlyIndexedProperty<TIndex, TValue>
{
readonly Func<TIndex, TValue> GetFunc;
public ReadOnlyIndexedProperty(Func<TIndex, TValue> getFunc)
{
this.GetFunc = getFunc;
}
public TValue this[TIndex i]
{
get
{
return GetFunc(i);
}
}
}
Set Only:
public class WriteOnlyIndexedProperty<TIndex, TValue>
{
readonly Action<TIndex, TValue> SetAction;
public WriteOnlyIndexedProperty(Action<TIndex, TValue> setAction)
{
this.SetAction = setAction;
}
public TValue this[TIndex i]
{
set
{
SetAction(i, value);
}
}
}
Example
Here's a simple usage example. I inherit from Collection and create a named indexer, as Jon Skeet called it. This example is intended to be simple, not practical:
public class ExampleCollection<T> : Collection<T>
{
public IndexedProperty<int, T> ExampleProperty
{
get
{
return new IndexedProperty<int, T>(GetIndex, SetIndex);
}
}
private T GetIndex(int index)
{
return this[index];
}
private void SetIndex(int index, T value)
{
this[index] = value;
}
}
ExampleCollection in the Wild
This hastily constructed unit test shows how it looks when you ExampleCollection in a project:
[TestClass]
public class IndexPropertyTests
{
[TestMethod]
public void IndexPropertyTest()
{
var MyExample = new ExampleCollection<string>();
MyExample.Add("a");
MyExample.Add("b");
Assert.IsTrue(MyExample.ExampleProperty[0] == "a");
Assert.IsTrue(MyExample.ExampleProperty[1] == "b");
MyExample.ExampleProperty[0] = "c";
Assert.IsTrue(MyExample.ExampleProperty[0] == "c");
}
}
Finally, if you want to use the get-only and set-only versions, that looks like this:
public ReadOnlyIndexedProperty<int, T> ExampleProperty
{
get
{
return new ReadOnlyIndexedProperty<int, T>(GetIndex);
}
}
Or:
public WriteOnlyIndexedProperty<int, T> ExampleProperty
{
get
{
return new WriteOnlyIndexedProperty<int, T>(SetIndex);
}
}
In both cases, the result works the way you would expect a get-only/set-only property to behave.
Well, the simpliest is to have the property return an object which implements IList.
Remember that just because it implements IList doesn't mean it's a collection itself, just that it implements certain methods.
I think the design you've posted is the way to go, with the one difference that I would define an interface:
public interface IIndexed<IndexT, ValueT>
{
ValueT this[IndexT i] { get; set; }
}
And for common cases, I would use the class you put in the original question (which would implement this interface).
It would be nice if the base class library provided a suitable interface for us, but it doesn't. Returning an IList here would be a perversion.
This doesn't answer your question, but it's interesting to note that CIL supports making properties like you've described - some languages (For example, F#) will allow you to define them in such a way too.
The this[] indexer in C# is just a specific instance of one of these which is renamed to Item when you build your app. The C# compiler only knows how to read this one, so if you write a "named indexer" called Target in an F# library, and try to use it in a C#, the only way you could access the property is via the ... get_Target(int) and void set_Target(int, ...) methods. Sucks.
Why not have your class inherit IList then you can just use the index and add your own properties to it. Although you will still have the Add and Remove functions its not dishonest not to use them. Plus you may find it useful to have them furthur down the road.
For more information about Lists and Arrays check out:
Which is better to use array or List<>?
EDIT:
MSDN has an article on index properties you may want to take a look at. Doesn't seem to complicated just tedious.
http://msdn.microsoft.com/en-us/library/aa288464(VS.71).aspx
There is another option where you can create an alternative Add method but depending on the type of object your add method may not always be called. Explained here:
How do I override List<T>'s Add method in C#?
EDIT 2: Similar to the first post
Why don't you have a hidden list object in your class and then just create your own methods for obtaining the data. That way Add and Remove aren't seen and the list is already indexed.
Also what do you mean by "named indexer" are you looking for the equivalent of the row["My_Column_Name"]. Theres an MSDN article I found that may be useful as it seems to show the basic way to implement that property.
http://msdn.microsoft.com/en-us/library/146h6tk5.aspx
class Test
{
private List<T> index;
public T this[string name]{ get; set; }
public T this[int i]
{
get
{
return index[i];
}
set
{
index[i] = value;
}
}
}
After some research, I came up with a slightly different solution that better fitted my needs. The example is a little concocted, but it does suit what I need it to adapt it to.
Usage:
MyClass MC = new MyClass();
int x = MC.IntProperty[5];
And the code to make it work:
public class MyClass
{
public readonly IntIndexing IntProperty;
public MyClass()
{
IntProperty = new IntIndexing(this);
}
private int GetInt(int index)
{
switch (index)
{
case 1:
return 56;
case 2:
return 47;
case 3:
return 88;
case 4:
return 12;
case 5:
return 32;
default:
return -1;
}
}
public class IntIndexing
{
private MyClass MC;
internal IntIndexing(MyClass mc)
{
MC = mc;
}
public int this[int index]
{
get { return MC.GetInt(index); }
}
}
}
Related: How can I use polymorphism in XML Serialization?
I have a class I wrote for serializing the user's preferences to disk between application sessions. To read/write I'm using XmlSerializer.Deserialize() and XmlSerializer.Serialize(). One property that gets serialized is a list of sub-settings for different application components. To accomplish this, I have something like the following (the property is only used during serialization):
private readonly Dictionary<SettingType, SubSettings> subSettings;
[XmlArray("SubSettings")]
[XmlArrayItem("SubSetting", Type=typeof(DictionaryEntry))]
public DictionaryEntry[] _SubSettings
{
get
{
int i = 0;
//Make an array of DictionaryEntries to return
DictionaryEntry[] result = new DictionaryEntry[subSettings.Count];
foreach( KeyValuePair<SettingType, SubSettings> setting in subSettings ) {
DictionaryEntry entry = new DictionaryEntry( setting.Key, setting.Value );
result[i] = entry;
i++;
}
return result;
}
set
{
subSettings.Clear();
for( int i = 0; i < value.Length; i++ )
subSettings.Add( (SettingType)value[i].Key, (SubSettings)value[i].Value );
}
}
That's been serving me perfectly well, with all the dictionary's values being SubSettings dynamically. The problem is that now I'd like to have some of the SubSettings objects be a different dynamic type (CoolSubSettings : SubSettings). The obvious problem is that if I do this, I won't be able to communicate as the XML is read what dynamic type each SubSettings node is supposed to be, and its additional properties will not be read or written.
This is because serializer does not know all the types, you must tell him which types it must use. For example, you cant try the following approach:
struct DictEntry<T>
{
public SettingType Key;
public T Value;
}
// ...
[XmlArray("SubSettings")]
[XmlArrayItem("SubSetting", Type=typeof(DictEntry<SubSettings>))]
[XmlArrayItem("CoolSubSetting", Type=typeof(DictEntry<CoolSubSettings>))]
public object[] _SubSettings
{
// ...
Update: Yet another solution for your problem:
struct DictEntry
{
public SettingType Key;
[XmlElement("SubSettingValue", Type=typeof(SubSettings))]
[XmlElement("CoolSubSettingValue", Type=typeof(CoolSubSettings))]
public object Value;
}
[XmlArray("SubSettings")]
public DictEntry[] _SubSettings
{
// ...
I think you understand main implementation idea? BTW, I am not sure about inheritance in this case, and I cannot test it right now. But in case of troubles you can create basic ancestor for both SubSettings and CoolSubSettings.