On Monday 07 October 2002 04:49 pm, Alexandre Julliard wrote:
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.
Greg Turner gmturner007@ameritech.net writes:
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.
-
Alexandre Julliard -
Greg Turner