Re: wine/dlls/rpcrt4 Makefile.in rpcrt4.spec rpcrt ...

[Greg Turner]

On Monday 07 October 2002 04:49 pm, Alexandre Julliard wrote:
> ChangeSet ID:	5665
> CVSROOT:	/opt/cvs-commit
> Module name:	wine
> Changes by:	[e-mail]	2002/10/07 16:49:49
>
> Modified files:
>    dlls/rpcrt4    : Makefile.in rpcrt4.spec rpcrt4_main.c
> Added files:
>    dlls/rpcrt4    : rpc_binding.c rpc_binding.h
>
> Log message:
>    Ove Kaaven 
>    Implemented RpcBindingInqObject, RpcBindingSetObject,
>    RpcBindingVectorFree, RpcBindingToStringBindingA/W,
>    RpcBindingFromStringBindingA/W, RpcStringBindingParseA/W,
>    I_RpcBindingSetAsync, RpcStringBindingComposeA/W, RpcBindingFree,
>    RPCStringFreeW, UUIDHash, UuidToStringW, and associated junk.
>
> Patch: http://cvs.winehq.com/patch.py?id=5665
>
> Old revision  New revision  Changes     Path
>  1.8           1.9           +1 -0       wine/dlls/rpcrt4/Makefile.in
>  1.19          1.20          +11 -10     wine/dlls/rpcrt4/rpcrt4.spec
>  1.29          1.30          +78 -73     wine/dlls/rpcrt4/rpcrt4_main.c
>  Added         1.1           +0 -0       wine/dlls/rpcrt4/rpc_binding.c
>  Added         1.1           +0 -0       wine/dlls/rpcrt4/rpc_binding.h

Interesting that you unrolled the #define macros in rpc_binding.c.

I guess the argument against this is that it creates code duplication.
The argument for it is more obvious (reduces insanity).  In general,
should I avoid submitting patches with big nasty #define's that
are really inline functions like this, even at the expense of duplicating 
some code?  Personally, I kind of dislike this sort of thing (big nasty 
#define's); but I notice that, to an extent, they abound in wine, and I 
must say that I dislike code duplication almost as much.

STL is a good compromise, for C++; but obviously that doesn't help us
here in C land (or does it?  anyhow, STL is probably not a desirable
dependency for wine IMHO).  M4 is already a dependency but would
be a pretty big break from the current way of doing things... if we're to drag
in M4 then we'd might as well rework all of wine to use it in place of the
big nasty #defines.... sounds like a miserable and tedious process, and when
it's all done, nobody can understand the code (including me, and M4 
ignoramus).  Ugh.

!%&!%& script-soup.  When did coding become so much like 
web-page design?  I blame Richard Stallman ;)  Rule of thumb:
Any program with backquoted backquotes is misdesigned! :)

Anyhow, now that I've gotten my bitching and moaning out 
of the way... let me know if you'd like me to break up #defines
like this in future patches and I'll do it.  As for the stuff that's
already checked in, I'm gonna look at the possibility of dropping
some of it into RPCRT4_ functions (/real/ functions) to reduce the
duplication.

wine/dlls/rpcrt4 Makefile.in rpcrt4.spec rpcrt ...

[Alexandre Julliard]

Greg Turner  writes:
> I guess the argument against this is that it creates code duplication.
> The argument for it is more obvious (reduces insanity).  In general,
> should I avoid submitting patches with big nasty #define's that
> are really inline functions like this, even at the expense of duplicating 
> some code?

Yes, a bit of code duplication is better than such massive macro
abuse. And if the duplicated code becomes too large, you can either
split it into separate functions, or implement the A function by
converting strings and calling the W function.