On 22/04/2025 02:06, Waldek Hebisch wrote:
bart <bc@freeuk.com> wrote:
I've seen a 33KB C file that expanded to 4MB after preprocessing. Macros
are evil.
If macros were forbiden authors would probably write 4MB "by hand"
(or rather using editor cut and paste). Actually, creating first
version probably would be not that hard, but maintanence would
take a lot of effort (due to volume).
It would probably be done by a script. This resulting code is not something to be written or consumed by a human. Which is an odd thing to say about a HLL.
The example below is not as bad: the lines are only up to 1K chars instead of 50K.
(I thought my own generated C code was poor; it's actually a million times more readable.)
Of course, macro generated code is likely to contain significant
fraction of useless instructions, but removing them by hand would
be substantial work. And trying to directly produce trimmed
version would need a lot of work. It is much cheaper to
depend on optimizer to remove redundancies and useless instructions.
How about writing decent, sensible code in the first place?
Assuming that hand written version would be 80% smaller, you would
have 800KB to write, that is more than 20 times the original
source. So in this case macros probably saved about 95% of
work needed when coding without macros.
You haven't seen this example, you don't know how bad it is, or how effective it was as a solution to whatever problem it was trying to solve, and yet YOU'RE MAKING EXCUSES FOR IT!
This is a really odd phenomenon: is there no C code on the planet, that anybody here will admit that is badly written? Or that might be forced into being badly written due to shortcomings of the language?
Here's a challenge for everyone here: please post an example, or a link to an example, that you think is truly appalling code.
Here's a nice example:
>
op_arith(L, l_addi, luai_numadd);
>
Innocent-looking isn't it? It expands to this:
>
{TValue*v1=(&((base+((((int)((((i)>>((((0+7)+8)+1)))&((~((~(Instruction)0)<<(8)))<<(0)))))))))->val);TValue*v2=(&((base+((((int)((((i)>>(((((0+7)+8)+1)+8)))&((~((~(Instruction)0)<<(8)))<<(0)))))))))->val);{StkId
ra=(base+(((int)((((i)>>((0+7)))&((~((~(Instruction)0)<<(8)))<<(0)))))));if(((((v1))->tt_)==(((3)|((0)<<4))))&&((((v2))->tt_)==(((3)|((0)<<4))))){lua_Integer
i1=(((v1)->value_).i);lua_Integer
i2=(((v2)->value_).i);pc++;{TValue*io=((&(ra)->val));((io)->value_).i=(((lua_Integer)(((lua_Unsigned)(i1))+((lua_Unsigned)(i2)))));((io)->tt_=(((3)|((0)<<4))));};}else{lua_Number
n1;lua_Number
n2;if((((((v1))->tt_)==(((3)|((1)<<4))))?((n1)=(((v1)->value_).n),1):(((((v1))->tt_)==(((3)|((0)<<4))))?((n1)=((lua_Number)(((((v1)->value_).i)))),1):0))&&(((((v2))->tt_)==(((3)|((1)<<4))))?((n2)=(((v2)->value_).n),1):(((((v2))->tt_)==(((3)|((0)<<4))))?((n2)=((lua_Number)(((((v2)->value_).i)))),1):0))){pc++;{TValue*io=((&(ra)->val));((io)->value_).n=(((n1)+(n2)));((io)->tt_=(((3)|((1)<<4))));};}};};};
>
From this, I had to find the bug in my compiler.
Not bad, I sometimes had to look for bugs in much bigger piece of
code.
So that means there's nothing wrong with it? Remember this is one expression.
(Lua is an interpreter; I write interpreters and they are several times
faster than Lua for equivalant inputs. I don't need to use such tricks.)
IIUC Lua has some interesting properties. Above I see masking and
tag manipulations, presumably this is needed to implement Lua
properties.
Here you are making excuses again. Yes, Lua uses tags on some 64-bit value; so what? That can be done using ordinary code. Or if macros have to be used, they can be simple too.
My own product uses apparently inefficient 128-bit values, it does everything 'wrong' but it uses readable HLL code with minimal use of macros, and yet it can run at several times the speed of Lua even unoptimised. You don't need to write gobbledygook.
BTW here is that macro definition from Lua:
#define op_arith(L,iop,fop) { \
TValue *v1 = vRB(i); \
TValue *v2 = vRC(i); \
op_arith_aux(L, v1, v2, iop, fop); }
It calls yet more macros, and those in turn call others; here are a few for vRB:
#define vRB(i) s2v(RB(i))
#define s2v(o) (&(o)->val)
#define RB(i) (base+GETARG_B(i))
#define GETARG_A(i) getarg(i, POS_A, SIZE_A)
#define getarg(i,pos,size) (cast_int(((i)>>(pos)) & MASK1(size,0)))
#define cast_int(i) cast(int, (i))
#define MASK1(n,p) ((~((~(Instruction)0)<<(n)))<<(p))
#define cast(t, exp) ((t)(exp))
I think the maximum depth here is 7-deep:
op_arith -> vRB -> RB -> GETARG -> getarg -> cast_int -> cast
This is not normal coding; it has replaced using functions to build programs, with macros. And it has replaced coding in C, with functional-style coding via the macro language.
So what language would say this program is written in?
I would expect that Lua has more than one artithemetic
operation, so sharing code saves coding effort (actually, most
of tag mainipulations probably can be shared by all Lua instructions).
Any reason to uses *seven* levels of macro invocation? That is all in one branch.
Do you think that's too many? Perhaps only 3 levels would have sufficed. Or would you automatically say it was reasonable no matter how many levels there were, just to disagee with me and to side with a fellow C programmer?
do { quit; } else { }
Re: do { quit; } else { }