On Fri, 6 Dec 2002, Ove Kaaven wrote: [...]
We may have to keep the macros anyway, there are headers that use them that can't be generated from IDL, like the DirectX headers. I suppose they could be converted to using the MS-style objbase.h macros by perl scripts or by rewriting them from api headers or something, but someone else would have to take on that task, I think.
IIRC, one of the problems with the MS macros is that they force you to repeat all the inherited functions everytime. I.e. whenever you declare a new COM class you have to add the same QueryInterface, AddRef and Release lines over and over again. For DirectX this is even worse when Xxx8 inherits from Xxx7 which inehrits from Xxx6, etc <g>.
The ICOM macros should be source and binary compatible with what's generated by the MSVC macros so I would just keep on using them since they should make the headers more readable and maintainable.
Also I would not be surprised if the MS macros were less flexible than the ICOM macros and required that you have a compiler that can generate C++ classes with just the right binary layout.
Concerning the array issue, isn't 'int[] a' equivalent to 'int a[]'? Then one could have things like:
ICOM_METHOD2(HRESULT,Foo,REFIID[],, LPVOID[],)
Or is it just that MSVC does not like the ',,' in macro invocations?