Do structs add any overhead to instance size?

Question

Specifically, if I make a struct that has a single field, that essentially acts as a wrapper around that value, is it safe to pass this struct to a P/Invoke method expecting the underlying type?

I'm working with a native library whose API involves a lot of pointer-to-struct types, and I'd like to use something a bit more typesafe than IntPtr to keep them all straight, by wrapping IntPtr in a generic struct. Would that work? (And has it already been done?)

Answer 1

Don't pass it as a struct, then.

Instead of figuring out how to do this directly with P/Invoke, just keep the P/Invoke methods private, and expose public methods that will take your wrapper type directly - and handle whatever you need to do to pass it forward. Your code is then only going to use these public methods without having to worry about unsafe structures :)

Mixing different types and expecting them to magically work is a recipe for disaster. Make yourself explicit, and don't rely on hiding and implicit forced casts.

The best thing about this is that it allows you to very easily use some pointer wrapper that is actually safe - you can keep it as a reference, and if it's ever lost, you can use a finalizer to dispose of the unmanaged resource as needed. Have a look at how SafeHandle and it's descendants work for a great sample.

Answer 2

So long as you use LayoutKind.Sequential, then the struct's single field will be located at offset zero. Therefore, your assumption is correct.

I presume that by pointer-to-struct type, you mean an opaque pointer. The struct is forward declared but never defined. However, in that case I cannot see how declaring a struct in your C# code can really help you. An opaque pointer is, well, opaque. Only the library implementation knows how to allocate it. You can't allocate it in the consumer.

Update

Perhaps you want to wrap an opaque pointer in a struct like this:

[StructLayout(LayoutKind.Sequential)]
struct FooHandle
{
    IntPtr handle;
}

// and so on for other handle types

Interop with this struct will be indistinguishable from interop with IntPtr.