Using reflection to emulate a pointer in managed code

[ThankGodItsFriday]

The problem I'd like to solve is to map a value type to a value in a hashtable in managed code.

public class testbase
{
   protected HashTable ht = new HashTable();
}

public class test : testbase
{
   string _aString;
   int _aInt;

   public test()
   {
      ht["aString"] = _aString;
      ht["aInt"] = _aInt;
   }

   public string aString
   {
      get {return _aString;}
      set {_aString = value;}
   }

   public int aInt
   {
      get {return _aInt;}
      set {_aInt = value;} 
   }
}

In unmanaged code I would simply declare the hashtable as

ht["aString"] = &_aString;

thus making sure that whenever _aString is modified the value for the key is also modified.

I can solve this by updating ht in the set-statement for each property, however I would like it to work the other way around as well - that is:

ht["aString"].value = "A new string"; // should automatically update _aString

I've been looking some in the System.Reflection namespace, but even though this gives my the possibility to return the name of the properties it doesn't seem to give me the ability to set them.

Is this at all possible to to in managed code? As far as I understand MS removed pointers to be able to implement garbage collection more efficiently, but is there a workaround?

// T.G.I.F.

 

[chiph]

Value types are never referenced by passing just a memory address -- they're always full copies. So no, you can't do that. But, you could "box" them by first converting them to a reference type variable ("object", in the worst case), and that variable you could certain pass by reference.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[ThankGodItsFriday]

One option would be to declare them as sql-types instead, as the reason I want this is to map an object onto a DB table.
(You could simply map the key name to the row-column name property.)

Do you know how well sql-types perform memorywise and speedwise compared to valuetypes?