Typically if C/C++ code uses a type in pointer form (i.e., T*) then this will be represented in the CLR as a reference (class) type. If it uses a type in value form (i.e., T) then it is represented as a value type in the CLR. E.g., you would typically port this C++ code

1
2
3
4
5
6
7
8

class A { 
  static void byVal(A* a);
  static void byRef(A** a);
};
class B { 
  static void byVal(B b);
  static void byRef(B* b);
};

to C# like so

1
2
3
4
5
6
7
8

class A { 
  static void byVal(A a);
  static void byRef(ref A a);
}
struct B { 
  static void byVal(B b);
  static void byRef(ref B b);
}

Most well-designed C++ libraries only use a type in T* or T form, so it is just a matter of choosing the appropriate struct or class representation in the CLR, and then you avoid any explicit use of pointer types and use the standard CLR null value. If your C++ library is not nice like this then you might have to do something more funky for interop.

You might like to familiarize yourself with the CLR's unmanaged code interop system before tackling the import of an unmanaged library.

The CLRs type saftey that prents you casting from a pointer to .NET type. It does provide you with some methods to help you marshal data between the managed and unmanaged worlds, these are containted in: System.Runtime.Interop.Marshal. The other thing you can do is create .NET structs that look like unmanaged types and use these with your api calls, there's a good example of how to do this in this thread: [link:cs.hubfs.net]

Cheers,
Rob