数组的C＃Interop封送处理行为似乎与文档不一致

Question

I am currently writing a thin C# binding for OpenGL. I've just recently implemented the OpenGL GenVertexArrays function, which has the following signature: OpenGL Documentation on glGenVertexArrays .

Essentially, you pass it an array in which to store generated object values for the vertex arrays created by OpenGL.

In order to create the binding, I use delegates as glGenVertexArrays is an OpenGL extension function, so I have to load it dynamically using wglGetProcAddress. The delegate signature I have defined in C# looks like this:

[SuppressUnmanagedCodeSecurity]
[UnmanagedFunctionPointer(CallingConvention.StdCall)]
private delegate void glGenVertexArrays(uint amount, uint[] array);

The function pointer is retrieved and converted to this delegate using Marshal.GetDelegateForFunctionPointer, like this:

IntPtr proc = wglGetProcAddress(name);

del = Marshal.GetDelegateForFunctionPointer(proc, delegateType);

Anyways, here's what bothers me:

In any official documentation I can find on default marshalling behaviour for reference types (which includes arrays), is this:

By default, reference types (classes, arrays, strings, and interfaces) passed by value are marshaled as In parameters for performance reasons. You do not see changes to these types unless you apply InAttribute and OutAttribute (or just OutAttribute) to the method parameter.

This is taken from this MSDN page: MSDN page on directional attributes

However, as can be seen from my delegate signatures, the [In] and [Out] directional attributes have not been used on the array of unsigned integers, meaning when I call this function I should actually not be able to see the generated object values which OpenGL should have stored in them. Except, I am. Using this signature, I can the following result when running the debugger:

As can be seen, the call absolutely did affect the array, even though I did not explicitly use the [Out] attribute. This is not, from what I understand, a result I should expect.

Does anyone know the reason behind this? I know it might seem as a minor deal, but I am very curious to know why this seems to break the default marshalling behaviour described by Microsoft. Is there some behind-the-scenes stuff going on when invoking delegates compared to pure platform invoke prototypes? Or am I misinterpreting the documentation?

[EDIT]

For anyone curious, the public method that invokes the delegate is defined on a static "GL" class, and is as followed:

public static void GenVertexArrays(uint amount, uint[] array)
{
    InvokeExtensionFunction<glGenVertexArrays>()(amount, array);
}

Answer 1

It is not mentioned on the documentation page you linked, but there is another topic dedicated to the marshaling of arrays, where it says:

With pinning optimization, a blittable array can appear to operate as an In/Out parameter when interacting with objects in the same apartment.

Both conditions are met in your case: array of uint is blittable, and there is no machine-to-machine marshaling. It is still a good idea to declare it [Out], so your intention is documented within the code.

Answer 2

The documentation is correct in the general case. But uint is a bit special, it is a blittable type. An expensive word that means that the pinvoke marshaller does not have to do anything special to convert the array element values. An uint in C# is exactly the same type as an unsigned int in C. Not a coincidence at all, it is the kind of type that a processor can handle natively.

So the marshaller can simply pin the array and pass a pointer to the first array element as the second argument. Very fast, always what you want. And the function scribbles directly into the managed array, so copying the values back is not necessary. A bit dangerous too, you never ever want to lie about the amount argument, GC heap corruption is an excessively ugly bug to diagnose.

Most simple value types and structs of simple values types are blittable. bool is a notable exception. You'll otherwise never have to be sorry for using [Out] even if it is not necessary. The marshaller simply ignores it here.