C# puzzle of the day

Lately I’ve been exploring old prototype code I wrote year ago. It always amazes me to se how my coding style changes over the years. It also intrigues me, because it’s a kind of cross between archeology and journaling. I can see what I was doing years ago. I wrote this little C++ memory simulation back in 2002, for a the memory component of a little CPU simulator:

struct memory
{
byte_t* mem;
unsigned int size;
memory(unsigned int x = vpc::mem_size)
  {
  mem = new byte_t[x];
  size = x;
  //memset(mem, 0, size);
  } 
~memory()
  {
  if(mem != 0)
    {
    delete mem;
    mem = 0;
    size = 0;
    }
  }

template<typename T>
T get(unsigned int idx)
  {
  return *(T*)(mem + idx);
  }

template<typename T>
T get(unsigned int base, unsigned int off)
  {
  return get(base + off);
  }

template<typename T>
void set(unsigned int idx, T& t)
  {
  *(T*)(mem + idx) = t;
  }
};
It’s easy to see how C++ grew out of Simula. There’s very little difference here between a simulation and the real thing. This could be part of a primitive memory manager if you enhanced it a little. It grabs a piece of memory, and then treats it as though it were a T. I just used the get and set methods to allow me to easily manipulate C++ data types from a test harness. I can only think of two ways to do this in C#. First was the MemoryStream class, that would allow you to serialize your objects into and out of memory, and the other would be the BitConverter class. BitConverter would be more efficient, but only supports primitive types. A serialized class is not much use at runtime, since you would have to deserialize it to use it.

I like this because it illustrates how a strongly typed language can be a hindrance. Last time I posted an entry criticising C# for lacking the power of C++, I got back some very intriguing responses that showed that with sufficient ingenuity, you can get around most hurdles in a language. So this time, I’m wondering how we could overcome this strong typing constraint. I know I’m a hypocrite for eulogising about strong typing in one post, and then criticising it in the very next. I guess I just want the power to not be bound by it, if I know what I am doing.

This must be an issue for C# communications libraries where they need to efficiently convert a byte stream into an object. Since all objects and classes are ultimately composed of primitives, I have to assume that recursive application of the BitConverter class is enough to impose shape on the data stream – but you would have to assign an object on a heap to store the data, so you can’t do what is done above.

How would you do this in C#?

2 thoughts on “C# puzzle of the day

  1. (No idea)
    But I can easily imagine the exact same question 20 years ago of C (and comparing it to assembler): “Type safety is great. How do you switch it off?”

    It’s also interesting that you’ve not forward extrapolated your ‘look back’, to envisage that you’ll have _elegantly_ found a generic serializing scheme in the future.

    I think the problem for language designers has remained largely the same over the years: close the semantic gap, without introducing issues unrelated to ‘The Problem’ e.g. speed/space/access efficiency.

  2. The difference between .NET today and C of 20 years ago is that .NET is a ‘managed’ runtime. Meaning it works on an idealised stack based machine, and you never get to see the real machine. C was different, there was always a way of reaching into the machine and dealing with wires. If you couldn’t do it with C instructions, you could always write asm{} blocks. C# has none of that. The nearest equivalent is the interop stuff that allows you to easily make calls out to COM components and other DLLs.

    The .NET framework is a vast and rich library and it’s entirely possible that I have missed a neat way that is employed by the APIs for serialisation or interop for doing this sort of thing. hence my post. I’m after a back door. I don’t think there should be one. It would be at odds with the language design, but you never know what compromises they had to make for practicality.

Comments are closed.