On 21/04/2025 21:25, Kaz Kylheku wrote:On 2025-04-21, bart <bc@freeuk.com> wrote:On 21/04/2025 19:43, Kaz Kylheku wrote:On 2025-04-21, bart <bc@freeuk.com> wrote:>On 21/04/2025 04:16, Kaz Kylheku wrote:>- Because they are not gathered in one place, not only is it less>readable, but we cannot use while write a macro such as:>>
for_sqlite_hash (p, &pSchema->trigHash) {
if (some_condition_over(p))
continue; // doesn't stupidly repeat for the same p!
}
I can't write such macros at all. I'm not even sure what this does.
Have you never worked with a large codebase written by someone other
than you?
How large are we talking about?
Several 100K to millions.
Characters, lines or files of source code, or bytes of binary?
I would say lines of code. In modern time 1 million characters
codebase is not big. I hope that we are not in era of 1 million
files codebases, but who knows, we may be there in few years.
I've delved into largish apps in the context of getting my C compiler
working. I would describe that experience as 'brutal'.
Well, that brutal experience is the job of the career software engineer,
believe it or not. Very few work only on their own original code.
If you need to
debug someone else's codebase, not to find bugs in that program, but to
find why your implementation is failing, then you want as conservative a
coding style as possible.
>
>When you open a random file in an unfamiliar code base, pretty>
much any function call that is not in the standard library triggers
the "I don't know what this does" response.
Yes, a function call. Macros are in an entirely different, evil category.
No, they aren't. They are just another definition to understand.
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).
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.
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.
They can be misused, and also used to make solutions that are more
complicated than some great ideas that don't involve macros.
You can tell when there is abuse going on, because you find that instead
of optimising doubling the speed of a program, it will make it 3-4 times
as fast. Because layers of macros hide the fact that that there are also
multiple layers of functions which need serious inlining.
Your abuse is another person "taking advantage of available technology".
One can write code in C so that rather dumb compiler will generate
reasobly fast program. But such code is harder to write and
error prone. Instead, one can write higher level code and
depend on optimizer to get good efficiency.
So can anything: an open coded function can be misused to make some
complicated solution that can be more nicely done with macros.The Lua sources (only a mere 30Kloc), use macros extensively, but also
have a habit of giving them ordinary looking names in lower case so that
they look like function calls.
So does ISO C; e.g. assert (expr); offsetof (type, member). So what?Macros that provide syntax should blend into the language.
These didn't provide syntax.
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.
(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. 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).
In many cases one can use functions instead of macros, but sometimes
macros depend on variable capture, so can not be replaced by functions.
Similarly, gotos (to label outside of a macro) and case labels
do not work well in inline functions. And in the past some compilers
were rather shy with inlining, which could significantly reduce speed.
--
Waldek Hebisch
| Date | Sujet | # | Auteur | |
| 23 Apr 26 |  … |
Les messages affichés proviennent d'usenet.