IntPtr arithmetics

Question

I tried to allocate an array of structs in this way:

struct T {
    int a; int b;
}

data = Marshal.AllocHGlobal(count*Marshal.SizeOf(typeof(T));
...

I'd like to access to allocated data "binding" a struct to each element in array allocated with AllocHGlobal... something like this

T v;
v = (T)Marshal.PtrToStructure(data+1, typeof(T));

but i don't find any convenient way... why IntPtr lack of arithmetics? How can I workaround this in a "safe" way?

Someone could confirm that PtrToStructure function copy data into the struct variable? In other words, modifing the struct reflect modifications in the structure array data, or not?

Definitely, I want to operate on data pointed by an IntPtr using struct, without copying data each time, avoiding unsafe code.

Thank all!

Answer 1

You have four options that I can think of, two using only "safe" code, and two using unsafe code. The unsafe options are likely to be significantly faster.

Safe:

• Allocate your array in managed memory, and declare your P/Invoke function to take the array. i.e., instead of:

  [DllImport(...)]
  static extern bool Foo(int count, IntPtr arrayPtr);
  

  make it

  [DllImport(...)]
  static extern bool Foo(int count, NativeType[] array);
  

  (I've used NativeType for your struct name instead of T, since T is often used in a generic context.)

  The problem with this approach is that, as I understand it, the NativeType[] array will be marshaled twice for every call to Foo. It will be copied from managed memory to unmanaged memory before the call, and copied from unmanaged memory to managed memory afterward. It can be improved, though, if Foo will only read from or write to the array. In this case, decorate the tarray parameter with an [In] (read only) or [Out] (write only) attribute. This allows the runtime to skip one of the copying steps.

• As you're doing now, allocate the array in unmanaged memory, and use a bunch of calls to Marshal.PtrToStructure and Marshal.StructureToPtr. This will likely perform even worse than the first option, as you still need to copy elements of the array back and forth, and you're doing it in steps, so you have more overhead. On the other hand, if you have many elements in the array, but you only access a small number of them in between calls to Foo, then this may perform better. You might want a couple of little helper functions, like so:

  static T ReadFromArray<T>(IntPtr arrayPtr, int index){
      // below, if you **know** you'll be on a 32-bit platform,
      // you can change ToInt64() to ToInt32().
      return (T)Marshal.PtrToStructure((IntPtr)(arrayPtr.ToInt64() +
          index * Marshal.SizeOf(typeof(T)));
  }
  // you might change `T value` below to `ref T value` to avoid one more copy
  static void WriteToArray<T>(IntPtr arrayPtr, int index, T value){
      // below, if you **know** you'll be on a 32-bit platform,
      // you can change ToInt64() to ToInt32().
      Marshal.StructureToPtr(value, (IntPtr)(arrayPtr.ToInt64() +
          index * Marshal.SizeOf(typeof(T)), false);
  }
  

Unsafe:

• Allocate your array in unmanaged memory, and use pointers to access the elements. This means that all the code that uses the array must be within an unsafe block.

  IntPtr arrayPtr = Marhsal.AllocHGlobal(count * sizeof(typeof(NativeType)));
  unsafe{
      NativeType* ptr = (NativeType*)arrayPtr.ToPointer();
  
      ptr[0].Member1 = foo;
      ptr[1].Member2 = bar;
      /* and so on */
  }
  Foo(count, arrayPtr);
  

• Allocate your array in managed memory, and pin it when you need to call the native routine:

  NativeType[] array = new NativeType[count];
  array[0].Member1 = foo;
  array[1].Member2 = bar;
  /* and so on */
  
  unsafe{
      fixed(NativeType* ptr = array)
          Foo(count, (IntPtr)ptr);
          // or just Foo(count, ptr), if Foo is declare as such:
          //     static unsafe bool Foo(int count, NativeType* arrayPtr);
  }
  

This last option is probably the cleanest if you can use unsafe code and are concerned about performance, because your only unsafe code is where you call the native routine. If performance isn't an issue (perhaps if the size of the array is relatively small), or if you can't use unsafe code (perhaps you don't have full trust), then the first option is likely cleanest, although, as I mentioned, if the number of elements you'll access in between calls to the native routine are a small percentage of the number of elements within the array, then the second option is faster.

Note:

The unsafe operations assume that your struct is blittable. If not, then the safe routines are your only option.

Answer 2

"Why IntPtr lack of arithmetics?"

IntPtr stores just a memory address. It doesn't have any kind of information about the contents of that memory location. In this manner, it's similar to void*. To enable pointer arithmetic you have to know the size of the object pointed to.

---

Fundamentally, IntPtr is primarily designed to be used in managed contexts as an opaque handle (i.e. one that you don't directly dereference in managed code and you just keep around to pass to unmanaged code.) unsafe context provides pointers you can manipulate directly.