-1

I am writing a small piece of code to serialize classes to binary that can be deserialized into an object without knowing the type on the receiving side. The type is defined in the assembly, but you don't have to provide it in the method call (e.g. Deserialize<MyType>()). I want to create some sort of a dictionary that allows me to get a Type from an int, and the corresponding int from a Type. Is there an object in .Net that does this?

I currently have a class with two private dictionaries and some methods to handle and validate the addition and removal of the synchronized dictionaries. The problem is, that's what I'm trying to avoid (duplicating data).

Edit: The solution proposed in the "Potential duplicate" is basically doing what I already am doing. I'm asking if there is a special dictionary class already doing this, which would allow one-to-one relations without duplicating every key and value.

Philippe Paré
  • 4,279
  • 5
  • 36
  • 56

2 Answers2

0

Create you own class with two private dictionaries (one Dictionary<int,type> the other Dictionary<type,int>). Create two methods IntToType and TypeToInt that will get data from their respective dictionaries. Then add a method Add(int i, Type t) that will add to both dictionaries. Since this is the only way to add to it (because they are private) there is no way for them to be out of sync.

Matt Burland
  • 44,552
  • 18
  • 99
  • 171
  • I specified in the question that this is already what I have. My question is: is this the way to do it, or is there a .Net object that does this without duplicating data. – Philippe Paré Sep 29 '15 at 15:47
  • 1
    Unless you have millions of classes, I wouldn't even worry about it. An `int` and a `type` isn't a lot of data. An `int` and a `type` multiplied by, say 100 then multiplied again by 2 (for the two dictionaries) still isn't a whole lot of data. – Matt Burland Sep 29 '15 at 15:48
  • My concern here is not really the size of the data really, I do feel like it shouldn't be twice as big, but I feel like this is a perfect place to introduce bugs. If there is no object already defined for this purpose, I will simply put more time into creating my own, checking every insertion and deletion correctly and so on... – Philippe Paré Sep 29 '15 at 15:51
  • @PhilippeParé: Hardly. You have two methods an `Add` and a `Remove` and you make sure that they are *the only two public methods that can change the underlying dictionaries*. Doesn't strike me as particularly prone to being buggy. – Matt Burland Sep 29 '15 at 15:53
  • I guess the answer has to be: there is no class that does this in .Net then... I know I can use two dictionaries, I know how to add and remove. Imagine I had memory constraints, what would you do in this case? – Philippe Paré Sep 29 '15 at 16:00
  • @PhilippeParé: Programming is about compromises and finding the best compromise to fit your situation. In the unlikely event that holding two dictionaries is impractical because of limited memory, then you'll have to use one dictionary and use `.FirstOrDefault` to do look ups in one direction. You'd be trading runtime for memory compactness. But if look ups in one direction are much rarer than the other, it might be okay. Or if there aren't that many items, but in that case, the memory problem wouldn't be so pressing. – Matt Burland Sep 29 '15 at 16:04
0

If you want fast access to get Type from int and otherwise int form Type, you have to duplicate data somehow. But if access time is not crucial in your situation you can just store one dictionary and write method like that to get key for specified value 

private Dictionary<int, Type> types;

public int GetIntForType(Type t)
{
    return types.FirstOrDefault(x => x.Value == t).Key;
}
marcin93w
  • 402
  • 6
  • 13
  • 1
    Depending on the usage case, this might be efficient enough. If looks ups from `int` to `type` are the most common, look ups from `type` to `int` are rare (and if the opposite is true, just use `Dictionary` instead of ``) and the number of items is small. – Matt Burland Sep 29 '15 at 15:56