microsoft/xlang

Please allow arrays in structs (enhancement request)

forderud opened this issue · 8 comments

forderud commented

I'm maintaining a code base that is currently leveraging "classic" COM structs like this for image data:

typedef [helpstring("2D image data")]
struct Image2d {
    [helpstring("")]                         double          time;
    [helpstring("Custom pixel format enum")] ImageFormat     format;
    [helpstring("width, height")]            unsigned short  dims[2];
    [helpstring("underlying image buffer")]  SAFEARRAY(BYTE) data;
} Image2d;

A COM method returning this Image2d struct will then give the client a full image data "object" in a single call. This is preferable for performance-sensitive out-of-proc communication where each COM call incur a double context switch. The the in-built oleaut32.dll "automation" marshaler will transport this struct fine both across process boundaries, regardless if the client is C++, C# or Python (using comtypes), making everything work smoothly from multiple languages. I'm also using custom marshalling for zero-copy image data exchange across process boundaries (using shared memory), but I guess that's a different topic.

I've recently started to "modernize" this struct to WinRT/MIDL3. The above struct would intuitively map to something like:

struct Image2d {
    Double      time;
    ImageFormat format; // custom pixel format enum
    UInt16      width;
    UInt16      height;
    UInt8[]     buffer; // error MIDL4000: A structure field cannot be a type of pointer
};

This unfortunately seem to trigger an error, indicating that arrays in structs are not supported. I've already seen this limitation mentioned in MicrosoftDocs/winrt-related#112 so I want to propose extending WinRT/MIDL3 to also support arrays in structs.

jaigak commented

In MIDL 3, arrays either represent a span (size + data) when passed as in parameter or an array specifically allocated by CoTaskMemAlloc when returned, with the expectation that the caller owns it and will call CoTaskMemFree, so it's not suitable for shared data. Usually, IBuffer or IMemoryBuffer is implemented for shared access where the caller doesn't directly manage the deallocation, but you can't put that currently inside a MIDL 3 struct.

forderud commented

.... you can't put that currently inside a MIDL 3 struct.

That's the reason for submitting this enhancement request in the first place. Is this the "right" project for MIDL3 enhancement requests, or should I instead submit it somewhere else?

jaigak commented

Is this the "right" project for MIDL3 enhancement requests, or should I instead submit it somewhere else?

I think it's better to submit it to the Visual Studio team at http://developercommunity.visualstudio.com/ because they maintain the MIDL compiler. Maybe not since this relates to the WinRT type system.

github-actions commented

This issue is stale because it has been open 10 days with no activity. Remove stale label or comment or this will be closed in 5 days.

forderud commented

Gentle reminder.

github-actions commented

This issue is stale because it has been open 10 days with no activity. Remove stale label or comment or this will be closed in 5 days.

forderud commented

Gentle reminder.

kennykerr commented

MIDL is limited to the WinRT type system which only supports arrays as parameters, not fields. The https://github.com/microsoft/win32metadata project aims to provide metadata for non-WinRT APIs as well and does support array fields.

I'm working on tooling that should eventually replace MIDL and support both WinRT and Win32 style metadata here: https://github.com/microsoft/windows-rs

  • 👍1
  • 😕2