On 02-11-18 22:01, Nikolay Sivov wrote:
On 11/02/2018 10:49 PM, Sven Baars wrote:
typedef struct _mfbytestream { + mfattributes attributes; IMFByteStream IMFByteStream_iface; + IMFAttributes IMFAttributes_iface; LONG ref;
} mfbytestream;
mfattributes already has IMFAttributes and refcount members.
+static inline mfbytestream *impl_from_IMFByteStream_IMFAttributes(IMFAttributes *iface) +{ + return CONTAINING_RECORD(iface, mfbytestream, IMFAttributes_iface); +}
+static HRESULT WINAPI mfbytestream_mfattributes_QueryInterface( + IMFAttributes *iface, REFIID riid, void **out)
With name like that I think it's better to move it to a separate file.
Hi Nikolay,
I removed the refcount member in the corrected patch that I sent. It seemed to have been added back in when rebasing the patches. Sorry for that. The IMFAttributes_iface (which uses mfbytestream_mfattributes_vtbl) I still need, because I forward it to attributes.IMFAttributes_iface, which is the actual implementation (uses mfattributes_vtbl).
I was not very happy about the long name either, but found another file in Wine where something similar was done, so I chose to do it like this. My personal preference would be to put every interface that I add in a separate file, since even the stubs are already 500+ lines. However, the tendency in Wine seems to be to put as much as possible into a single file. When is it OK to create a new one? Also, what would be the best way to handle different implementations of the same interface? If I add those in the same file, I would still possibly get names like mfbytestream_file_QueryInterface and mfbytestream_stream_QueryInterface (for MFCreateFile and MFCreateMFByteStreamOnStream).
Best, Sven