1

I have a C-Style API with methods that return pointers to native objects, e.g.

EXPORT hs::Pose3d* getJointEndPose(dh::Joint* joint);

And in C#,

[DllImport("Solver.dll")]
public static extern IntPtr getJointEndPose(IntPtr j);

To make the API a little nicer, I would like to distinguish between the types that the IntPtr's are pointing to. If the extern declarations can be made type-safe, that would be great, but even just more descriptive return types would be better than nothing.

Subclassing IntPtr is not possible because structs can't be inherited in C#. A using directive only applies to the file it's in.

Is there another way?

1 Answer 1

5

My recommendation here is to keep the imported functions private inside some class, and use objects of that class to replace the IntPtr. For example, like this:

class Foo
{
    [DllImport("Solver.dll")]
    private static extern IntPtr GetHandle();

    private IntPtr handle;

    public Foo()
    {
        handle = GetHandle();
    }
    
    // certain operations on handles
}

Now Foo becomes the typesafe replacement for the original IntPtr. In reality, Foo may encapsulate more than just one library call, and you may consider not to initialize Handle immediately in the constructor, but I guess you get the idea.

Of course, if you don't want to approach this "OO style", noone is hindering you to use a new struct with just one IntPtr attribute for each type of IntPtr, and introduce a mapping function for each imported function somewhere else, outside of those structs. Lets say we call the function GetJointEndPose to encapsulate getJointEndPose

struct Pose3D
{
    public readonly IntPtr IntPtr;
    public Pose3D(IntPtr x)
    {
        IntPtr = x;
    }
}
struct Joint
{
    public readonly IntPtr IntPtr;
    public Joint(IntPtr x)
    {
        IntPtr = x;
    }
}

 // ... somewhere else ...:
  public Pose3D GetJointEndPose(Joint joint)
  {
       return new Pose3D(getJointEndPose(joint.IntPtr));
  }

That gives you more descriptive return types, which can be used in a typesafe manner, but not much encapsulation, since it leaves access to the public IntPtr attribute open.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.