LPJUNK for COM Interfaces (Was: Re: [PATCH 1/3] dmloader: COM cleanup of IDirectMusicLoader object.)

[Michael Stefaniuc]

On 11/06/2012 11:05 PM, Christian Costa wrote:
>> Sure, separate patch to remove the duplicate name is fine. Just start
>> with that as it makes the subsequent COM cleanup patch shorter as it
>> cleans up the function header (whitespace and LPJUNK).
> That's what I try to do altough I don't clearly understand what the
> problem with LPJUNK stuff.
For the "normal" LPJUNK there is no problem. Except the programmers that
use it. Then you get beautiful code like:
include/rpcasync.h:RPCRTAPI RPC_STATUS RPC_ENTRY
RpcGetAuthorizationContextForClient(RPC_BINDING_HANDLE,BOOL,LPVOID,PLARGE_INTEGER,LUID,DWORD,PVOID,PVOID*);

LPVOID, PVOID, PVOID*
In the same line.

If they would have used LPVOID, LPVOID, LPLPVOID I could have at least
appreciate their effort to stay consistent. Of course there is no
LPLPVOID...

So for the normal LPJUNK inconsistency is the main issue and there is
code out there that uses every possible permutations of saying void*. In
the same function. Adding "const" into the mix makes it more "interesting".
But overall it is easy to decode: you tread a postfix "*" for a prefix "LP":
LPVOID => VOID*
No surprises there even if you count in the two notable exceptions:
LPSTR ==> char *
LPWSTR ==> WCHAR *


The LPJUNK for COM interface types has a far bigger problem, it looses
information:
LPDIRECTSOUNDBUFFER ==> DIRECTSOUNDBUFFER* ??

Add some LPDSCBUFFERDESC and similar to the same line of code and you
lost track. I'm singling out dsound here but ddraw/d3d with their
monster functions with 10+ parameters was way worse to figure out.
Especially when the implementation was LPJUNK casting those parameters
to pass them to other functions: Is there a object <==> interface cast
hidden there? Or maybe a cast from one interface to the other where it
should instead use QueryInterface?

bye
	michael