On 02/01/2024 23:24, tTh wrote:
> On 1/2/24 21:24, Bart wrote:
>>
>> You missed my point. Take a tiny feature like being able to easily get
>> the size of a fixed-length array. You commonly see macro like this:
>>
>>     #define LENGTH(a) (sizeof(a)/size(a[0]))
>
>    And why is that bad? That's a real question.

Where do I start?

* Why is it necessary for a million programmers to each come up with
their own solutions for something so basic? Eg. they will all use
diferent names.

* What happens when you merge or copy&paste code form different sources,
which use different macros for the same thing?

How does it work in practice: does everyone have a personal header full
of this stuff (bits missing from the language)? That will make it
awkward to post short programs to forums as now they have this extra
dependendcy.

Personally I can never bothered to write such macros in throwaway
programs, I just either write the whole thing in situ, or hard-code the
size if I know what it is anyway:

char* names[] = {"one", "two", "three", "four"};

for (int i=0; i<4; ++i)
puts(names[i]);

Rather than write:

for (int i=0; i<sizeof(names)/sizeof(names[0]); ++i) puts(names[i]);

It's all just so messy and annoying.

How hard is it to make it built-in to the language? I tried it just now
and it was about 20 lines of code to allow me to instead write:

char* names[] = {"one", "two", "three", "four"};

for (int i=0; i<lengthof(names); ++i)
puts(names[i]);

It took about 20 minutes. This could have been done in 1972.

On 03/01/2024 02:40, Lawrence D'Oliveiro wrote:
> On Wed, 3 Jan 2024 02:08:40 +0000, Bart wrote:
>
>> You guys don't seem to get it.
>
> Another thing we do is, not to bother repeating work that others have
> already done.
>
> sudo apt-get install libgmp-dev
>
> Job done.

OK, I've done that. But it didn't take 5 minutes as it did to compile it.

So I guess it is installing ready-built binaries?

In that case, why are people having a go at me for suggesting they
should be available to Windows users? Why are Linux users so blessed?

I notice that it no longer matters whether string.h is available. (Nor
apparently, the exact capabilities of my processor.)

Why it was ever an issue not clear. But it seems it only matters when
building this product.

Once it is a binary, then it doesn't matter. All the more reason why
such fussy bits of software should be preprocessed centrally, so that I
either get a binary, or an easy-to-compile blob of C code.

On 03/01/2024 12:10, Bart wrote:
> On 03/01/2024 02:40, Lawrence D'Oliveiro wrote:
>> On Wed, 3 Jan 2024 02:08:40 +0000, Bart wrote:
>>
>>> You guys don't seem to get it.
>>
>> Another thing we do is, not to bother repeating work that others have
>> already done.
>>
>> sudo apt-get install libgmp-dev
>>
>> Job done.
>
> OK, I've done that. But it didn't take 5 minutes as it did to compile it.
>
> So I guess it is installing ready-built binaries?
>
> In that case, why are people having a go at me for suggesting they
should be available to Windows users? Why are Linux users so blessed?
>

It gets more puzzling: on Linux for which the build process was designed
to run on, and where it is likely to work, users don't even need to
bother to do it, as there may be a ready-to-use version available.

But on Windows, where it is impossible to build without using so many
Linux elements (even 'info' to read the docs, and remember that weird
'JUNCTION' header?), there is no official binary. (Just lots of dubious
gmp.dlls with unfeasibly small sizes from dodgy-looking DLL sites.)

It's almost like they did it on purpose. Then I came across this comment
from 2016:

"Worth noting that there's quite a bit of beef between GMP and MPIR.

The GMP devs hate Windows and anything Microsoft. It's quite obvious
from the tone of language in their mailing lists.

This hostility towards Windows is why MPIR was made. So then the GMP
devs started hating on MPIR probably because it became a competitor."

This is just sad. It does sound as though the GMP people crammed in as
many Linux dependencies as possible just to spite MS.

I remember similar attitudes from the creators of Zig: they deliberately
chose not to support source files with CRLF line endings, because they
hated MS. Although later they did allow them.

(I remember needing to write a CRLF to LF conversion tool just to be
able to compile hello.zig.)

Bart <bc@freeuk.cm> writes:
>On 02/01/2024 23:24, tTh wrote:
>> On 1/2/24 21:24, Bart wrote:
>>>
>>> You missed my point. Take a tiny feature like being able to easily get
>>> the size of a fixed-length array. You commonly see macro like this:
>>>
>>>     #define LENGTH(a) (sizeof(a)/size(a[0]))
>>
>>    And why is that bad? That's a real question.
>
>Where do I start?
>
>* Why is it necessary for a million programmers to each come up with
> their own solutions for something so basic? Eg. they will all use
> diferent names.

Why is it necessary to exaggerate?

I've not seen that particular macro in the last forty years, myself.

LENGTH isn't even the proper macro name in this case; QUANTITY or NUM_ELEMENTS
would likely be more appropriate.

I have, of course, seen the idiom used often - it's quite normal and
standard.

e.g.
/*
* Table of Pentium MSR's to allow the Guest to access directly.
*
* XXX - Note that if the guest is allowed to access these MSR's
* directly, then they must be preserved and restored when the
* guest is migrated to a different core.
*/
static int pentium_msr_passthrough[] = {
MSR_SYSENTER_CS,
MSR_SYSENTER_EIP,
MSR_SYSENTER_ESP,
};
static const size_t PENTIUM_MSR_PT_CNT =
sizeof(pentium_msr_passthrough) / sizeof(pentium_msr_passthrough[0]);

/*
* Table of K6 MSR's to allow the guest to access directly.
*
* See caveat above.
*/
static int k6_msr_passthrough[] = {
MSR_KERN_GS_BASE,
MSR_USER_GS_BASE,
MSR_FS_BASE,
MSR_STAR,
MSR_LSTAR,
MSR_CSTAR,
MSR_SFMASK,
MSR_TSC_AUX,
};

static const unsigned int K6_MSR_PT_CNT =
sizeof(k6_msr_passthrough) / sizeof(k6_msr_passthrough[0]);

Bart <bc@freeuk.cm> writes:
>On 03/01/2024 02:40, Lawrence D'Oliveiro wrote:
>> On Wed, 3 Jan 2024 02:08:40 +0000, Bart wrote:
>>
>>> You guys don't seem to get it.
>>
>> Another thing we do is, not to bother repeating work that others have
>> already done.
>>
>> sudo apt-get install libgmp-dev
>>
>> Job done.
>
>OK, I've done that. But it didn't take 5 minutes as it did to compile it.
>
>So I guess it is installing ready-built binaries?
>
>In that case, why are people having a go at me for suggesting they
>should be available to Windows users? Why are Linux users so blessed?

Because linux is open source and the GNU team doesn't support closed-source
source operating environments like Windows.

scott@slp53.sl.home (Scott Lurndal) writes:
> Bart <bc@freeuk.cm> writes:
>>On 03/01/2024 02:40, Lawrence D'Oliveiro wrote:
[...]
>>In that case, why are people having a go at me for suggesting they
>>should be available to Windows users? Why are Linux users so blessed?
>
> Because linux is open source and the GNU team doesn't support closed-source
> source operating environments like Windows.

And nobody here is responsible for that fact (I'm not aware that any GNU
developers participate in comp.lang.c), but you behave as if it's our
fault.

As far as I know, GnuMP is not Linux-specific. It should work just fine
on other Unix-like operatoring systems, such as the various *BSDs.
I've probably used it on Solaris

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 02/01/2024 21:24, Bart wrote:
> On 02/01/2024 17:34, David Brown wrote:
>> On 02/01/2024 17:12, Bart wrote:
>
>>> X-macro are ugly. They are unreadable.
>>
>> Speaking as someone who has used them in real code, rather than
>> someone with a pathological hatred of macros and who prefers knee-jerk
>> reaction to their uses instead of applying a few minutes objective
>> thought, "x-macros" can make code significantly simpler, clearer, and
>> much easier to maintain correctly.
>
>
> I'm sorry, but I *DO* find them utterly impossible. This is a simple
> example from Stackoverflow of someone wanting to define a set of enums
> with an accompanying table, whose problem was in ensuring the two were
> kept in sync.
>
> The X-macro solution was this, adapted from the first answer here
> (https://stackoverflow.com/questions/6635851/real-world-use-of-x-macros); assume those functions are in scope:
>
> -------
>
> #define STATE_TABLE \
>         ENTRY(STATE0, func0) \
>         ENTRY(STATE1, func1) \
>         ENTRY(STATE2, func2) \
>         ENTRY(STATE3, func3) \
>
> enum
> {
> #define ENTRY(a,b) a,
>     STATE_TABLE
> #undef ENTRY
>     NUM_STATES
> };
>
> void* jumptable[NUM_STATES] =
> {
> #define ENTRY(a,b) b,
>     STATE_TABLE
> #undef ENTRY
> };
> -------

(Why did you change the type from "p_func_t" to "void*" ? Was it just
to annoy myself and other C programmers with a pointless and
constraint-violating cast of a function pointer to "void*" ? Just add a
suitable typedef - "typedef void(*p_func_t)(void);" )

That's a fairly ugly way to express x-macros. It is neater to have the
extractor macro as a parameter to the list macro. Of course, you'd know
that if you read the stack overflow link you gave, since it comes
slightly below the code you copied. But presumably you preferred to use
the ugliest version that you could pretend was hard to understand (it
isn't), rather than using the improved version.

I personally like to use a slightly different syntax, but that's just
detail and style choice.

#define DoStateList(DO) \
DO(state0, func0) /* Comment */ \
DO(state1, func1) \
DO(state2, func2) \
DO(state3, func3) \

#define GetState(state, func) state,
#define GetFunc(state, func) func,
#define Counter(state, func) +1

enum { num_of_states = DoStateList(Counter) };

enum States {
DoStateList(GetState)
};

p_func_t jump_table[] = {
DoStateList(GetFunc)
};

Note that the states can have comments. You do need a backslash at the
end of each line, and that means comments must be /* */ style, not // style.

It is, of course, quite possible to have generic "Get1", "Get2", etc.,
macros rather than "GetState", "GetFunc".

And since we have the x-macro in place, we can use it for more things.
Why manually declare "extern void func0(void);", etc., when you can do
it in two lines for all the functions?

#define DeclareFunc(state, func) extern void func(void);
DoStateList(DeclareFunc)

Maybe you want a switch rather than a jump table - that could give more
inlining opportunities, and is a common choice for the structure of
things like simple VM's and bytecode interpreters:

#define SwitchEntry(state, func) case state : func(); break;
void jump(enum States s) {
switch (s) {
DoStateList(SwitchEntry);
}
}

There are lots of possibilities here. It's not perfect, and some
complex cases might need a bit of testing debugging (godbolt.org with
the "-E" compiler flag is extremely convenient for this), but testing
and debugging is part of a programmer's daily life.

Overall, it's a code generation technique that can be useful whenever
you need repetitive code patterns. It can also be useful for some kinds
of compile-time calculations (such as setting up tables for CRC
functions.) I would not use it when higher level features could do a
better job - if C++ templates and constexpr functions are clearer, I'd
use them. And sometimes they are not enough, or not clear enough, and
I'd make a Python script to generate the C code. But that applies to
everything in programming, really - you should always look for the best
tool for the job.

>
>
> With my feature, it is merely this:
>
>     global enumdata []ref void jumptable =
>         (state1, func1),        # comment 1
>         (state2, func2),
>         (state3, func3),        # comment 3
>         (state4, func4),
>     end
>

That is an very niche and very limited use-case. Did you seriously add
a special feature to your language based on one example in one stack
overflow question? X macros are just an imaginative way to use a
standard feature of C (and C++), giving vastly more flexibility than
your single-use language feature. I have difficulty seeing how it was
worth the effort putting that feature in your tools.

> Notice:
>
> (1) I don't need any of those weird macros.

They are quite simple. You pretend not to understand them, but this is
/not/ hard.

>
> (2) I don't need those backslashes

The backslashes are a minor inconvenience. I'd prefer if they were
unnecessary. It would be nice if C had something like a "#begindef" and
"#enddef" pair for making multi-line macros without backslashes.

>
> (3) I can add comments to any entry in the table.

So can I.

>
> (4) The 'global' attribute means both enumeration names and the array
>     are exported to other modules. Doing the same in C is tricky.

It is not tricky in C - if you want the enumerated type to be accessible
from other units, put it in a header. If you want the functions that
are called to be internal to an implementation file and not mentioned in
the header, just have the state names in the header and use token
pasting to make function names automatically - something like
"state0_handler" - in the implementation file. Simple, consistent,
clear, and it is almost impossible to change the states out of sync with
the handlers without leading to a compile-time error. And /that/ is the
main purpose - not reducing typing, or looking neat.

(I do not think C's way of handling import/export of symbols is ideal.
It might be that your language's way is better, in at least some ways.
But since this is C, we do it the C way.)

>
> But I'm wasting my time because you are never going to admit my feature
> is superior to X-macros for this purpose.

It's not. Your feature is fine for a very limited use-case, but it is
not close to the flexibility of x-macros.

Let's try a more advanced example.

#include <stdio.h>
#include <string.h>
#include <stdbool.h>

#define REMOVE_COMMAS_(_1, _2, _3, _4, _5, _6, _7, _8, ...) \
_1 _2 _3 _4 _5 _6 _7 _8
#define REMOVE_COMMAS(...) REMOVE_COMMAS_(__VA_ARGS__, ,,,,,,,,)

#define DoCommandList(DO, P, Pvoid) \
DO(show, "Show item i", (i), P(int, i)) \
DO(run, "Run item i with val x", (i, x), P(int, i), P(double, x)) \
DO(hcf, "Stops the whole system and burns everything", (), Pvoid) \
DO(help, "Shows help for all the commands", (), Pvoid) \

#define DeclareFunc(cmd, help_text, params, ...) \
bool cmd_ ## cmd(__VA_ARGS__);

#define P_declare(type, name) type name
#define Pvoid_declare void
DoCommandList(DeclareFunc, P_declare, Pvoid_declare)

#define ShowHelp(cmd, help_text, params, ...) \
printf(" " #cmd REMOVE_COMMAS(__VA_ARGS__) " - " help_text "\n");
#define P_help(type, name) " " #name "(" #type ")"
#define Pvoid_help

bool cmd_help(void) {
printf("Help: \n");
DoCommandList(ShowHelp, P_help, Pvoid_help)
printf("\n\n");
return true;
}

int get_int_param(void);
double get_double_param(void);

#define RunCommand(cmd, help_text, params, ...) \
if (strcmp(command, #cmd) == 0) { \
REMOVE_COMMAS(__VA_ARGS__) \
return cmd_ ## cmd params; \
}
#define P_run(type, name) type name = get_ ## type ## _param();
#define Pvoid_run

bool dispatch_command(const char * command) {
DoCommandList(RunCommand, P_run, Pvoid_run)

printf("Unknown command - try \"help\"\n");
return false;
}

Now, some of that is messy - no doubts there. Some things could have
been a lot easier if C macros were more powerful, with features such as
recursion or neater handling of variadic packs. Macro names scoped
within functions would also make it better. So there's plenty of room
for a new language to make things better than C.

On 03/01/2024 15:32, Scott Lurndal wrote:
> Bart <bc@freeuk.cm> writes:
>> On 02/01/2024 23:24, tTh wrote:
>>> On 1/2/24 21:24, Bart wrote:
>>>>
>>>> You missed my point. Take a tiny feature like being able to easily get
>>>> the size of a fixed-length array. You commonly see macro like this:
>>>>
>>>>     #define LENGTH(a) (sizeof(a)/size(a[0]))
>>>
>>>    And why is that bad? That's a real question.
>>
>> Where do I start?
>>
>> * Why is it necessary for a million programmers to each come up with
>> their own solutions for something so basic? Eg. they will all use
>> diferent names.
>
> Why is it necessary to exaggerate?

How do you know whether I'm exaggerating or not? There have surely been
many millions of people who've programmed in C over the years.

And a large proportion may have needed the length of an array whose
dimensions are not set by a constant, but by the number of data elements
provided.

(Even in the former case, if you have int A[N] and B[N], I think it is
better to have 'LENGTH(A)' within the subsequent code, rather than a
bare 'N' which could mean anything: is it the length or A, B, or does it
mean N by itself? What happens if you change it to A[M]?)

So there could well have been million people who have created such a
macro, or at least, have had to do it a million times in all.

And if not, the rest would have to write code like this:

> static const size_t PENTIUM_MSR_PT_CNT =
> sizeof(pentium_msr_passthrough) / sizeof(pentium_msr_passthrough[0]);

If you have two similar-sounding arrays, it is easy to mix them up.

Or, somebody reading this code will have to double-check it, to ensure
tha names are identical, to be sure that it /is/ the idiom to get an
array length.

With my suggested feature, and in my style, it would look like this:

enum {PENTIUM_MSR_PT_CNT = lengthof(pentium_msr_passthru)};

(Although this would limit the number of entries in that array to about
2 billion, which would make for a rather large source file.)

On Wed, 3 Jan 2024 13:03:18 +0000, Bart wrote:

> It's almost like they did it on purpose.

It’s all a conspiracy, don’t you know. Microsoft is the poor, long-
suffering Donald Trump of the computing world--everybody is against them.

> It does sound as though the GMP people crammed in as
> many Linux dependencies as possible just to spite MS.

And Microsoft is totally powerless to prevent it. It’s like it has no
development resources of its own to come up with anything better.

On 03/01/2024 18:14, Bart wrote:
> On 03/01/2024 15:32, Scott Lurndal wrote:
>> Bart <bc@freeuk.cm> writes:
>>> On 02/01/2024 23:24, tTh wrote:
>>>> On 1/2/24 21:24, Bart wrote:
>>>>>
>>>>> You missed my point. Take a tiny feature like being able to easily get
>>>>> the size of a fixed-length array. You commonly see macro like this:
>>>>>
>>>>>      #define LENGTH(a) (sizeof(a)/size(a[0]))
>>>>
>>>>      And why is that bad? That's a real question.
>>>
>>> Where do I start?
>>>
>>> * Why is it necessary for a million programmers to each come up with
>>>    their own solutions for something so basic? Eg. they will all use
>>>    diferent names.
>>
>> Why is it necessary to exaggerate?
>
> How do you know whether I'm exaggerating or not? There have surely been
> many millions of people who've programmed in C over the years.
>

And how many of them define or use such a macro? Some, certainly, but
not all. I can't say I have ever had one in my code as far as I
remember. Occasionally I find it convenient to calculate the size of an
existing array, but I'll just write it manually as an expression (like
Scott seems to do). Generally if I need the size of an array, I already
know it - I can use the same "no_of_samples" (or whatever) constant I
used when defining the array in the first place.

> And a large proportion may have needed the length of an array whose
> dimensions are not set by a constant, but by the number of data elements
> provided.

I have no basis to guess whether this proportion is large or small. I
don't imagine you do either.

>
> (Even in the former case, if you have int A[N] and B[N], I think it is
> better to have 'LENGTH(A)' within the subsequent code, rather than a
> bare 'N' which could mean anything: is it the length or A, B, or does it
> mean N by itself? What happens if you change it to A[M]?)

The trick is not to use single letter identifiers when you want their
meaning to be clear.

I would not object to there being a standard C macro for finding the
size of an array. But I think it would be out of character for the
standard library. It would make more sense if the language had more
support for arrays and allowing them as values, parameters, and in
expressions - then a standard "size" feature would be expected.

On 02/01/2024 20:54, Janis Papanagnou wrote:
> On 02.01.2024 20:35, Lawrence D'Oliveiro wrote:
>> On Tue, 2 Jan 2024 20:23:24 +0100, Janis Papanagnou wrote:
>>
>>> That said; during my early K&R C era we had 'register' declarations, but
>>> I rarely saw them, they seem to have quickly vanished from usage. Now
>>> I've heard that 'inline' optimizations have been introduced in C. Isn't
>>> that considered a task for the compiler?
>>
>> Kids’ stuff. Want to see how a _real_ compiler does it?
>> <https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Attribute-Syntax.html>
>
> What shall I infer from that statement and link? - Mind to elaborate?
>
> My original question was related to compiler (as opposed to programmer)
> doing optimizations. I recall from decades ago that compilers will do
> optimizations e.g. on the attributed syntax tree level, while 'register'
> or 'inline' seem very primitive constructs (on a comparable low level).
> So I expressed my astonishment that 'inline' had been later introduced
> in C, and I wonder why. (Note that the other poster also mentioned it
> as a preferred way to replace [parameterized] macros, if I interpreted
> him correctly.)
>
> Janis
>

Lua is designed to be highly portable, including to compilers that are
not good at optimising, or are limited to old C dialects. (Many
programmers think the world consists of Windows, Linux, and Macs, but C
is used regularly on hundreds of different architectures, some of which
are very limited and/or have very poor quality tools.) If you only ever
have to deal with good quality tools on reasonable target processors,
then you are correct that you should focus on writing good, clear, safe
code, and let the compiler handle the low-level optimisations.

"register" is pretty much useless, and ignored for most compilation
(except for the side-effect that you cannot take the address of a
register variable). In C++, it's function as a storage-class specifier
has been removed so that it is available for completely different uses
in the future.

"inline" in C is really just a hint that the compiler should make the
function as fast as possible, but on simpler compilers (or advanced
compilers with only simpler optimisation enabled) it can be treated as a
strong hint. It also allows you to have a local "inline" definition for
a function and a separate external linkage version, but I advise against
that as unhelpful and potentially confusing - IMHO, inline functions
should always be static.

(In C++, "inline" means there may be more than one definition of the
function or object in the program, but you promise that all of them will
be equivalent.)

On 2024-01-03, David Brown <david.brown@hesbynett.no> wrote:
> On 03/01/2024 18:14, Bart wrote:
>> On 03/01/2024 15:32, Scott Lurndal wrote:
>>> Bart <bc@freeuk.cm> writes:
>>>> On 02/01/2024 23:24, tTh wrote:
>>>>> On 1/2/24 21:24, Bart wrote:
>>>>>>
>>>>>> You missed my point. Take a tiny feature like being able to easily get
>>>>>> the size of a fixed-length array. You commonly see macro like this:
>>>>>>
>>>>>>      #define LENGTH(a) (sizeof(a)/size(a[0]))
>>>>>
>>>>>      And why is that bad? That's a real question.
>>>>
>>>> Where do I start?
>>>>
>>>> * Why is it necessary for a million programmers to each come up with
>>>>    their own solutions for something so basic? Eg. they will all use
>>>>    diferent names.
>>>
>>> Why is it necessary to exaggerate?
>>
>> How do you know whether I'm exaggerating or not? There have surely been
>> many millions of people who've programmed in C over the years.
>>
>
> And how many of them define or use such a macro? Some, certainly, but
> not all.

I've seen it a lot. If it didn't have issues, it would be an excellent
inclusion in <stddef.h>, along with offsetof(type, member) and such.

Macros with issues should not be standardized though. For instance min
and max macros appear regularly in C programs, but feature multiple
argument evaluation.

For these kinds of things, it's better to wait until the language
develops a good solution. min and max want to be type-generic inline
functions. I think that this is doable in C with _Generic. In the
April 2023 draft, I don't see any min functions other than fminf,
fmin and fminl, which are float, double and long double. No generic
min and max are mentioned for <tgmath.h>

There are probably too many combinations to handle; you need
two levels of _Generic selection, each switching on a number of integer
and floating-point types. (There being reams and reams of templates
doesn't stop C++, though.)

For counting the elements in an array, we really want a sizeof-like
keyword, which takes a parenthesized type or expression. That expression
is constrained to be of array type.

(Might it be possible with _Generic to detect that we have an operand
which is an "array of anything"? I'm guessing not.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 03/01/2024 16:41, David Brown wrote:
> On 02/01/2024 21:24, Bart wrote:

> I personally like to use a slightly different syntax, but that's just
> detail and style choice.
>
>
> #define DoStateList(DO) \
>         DO(state0, func0) /* Comment */ \
>         DO(state1, func1) \
>         DO(state2, func2) \
>         DO(state3, func3) \
>
> #define GetState(state, func) state,
> #define GetFunc(state, func) func,
> #define Counter(state, func) +1
>
> enum { num_of_states = DoStateList(Counter) };
>
> enum States {
>     DoStateList(GetState)
> };
>
> p_func_t jump_table[] = {
>     DoStateList(GetFunc)
> };
>
>

I admit that your version is cleaner than other versions of X-macros
I've come across. I can almost even understand it.

But nearly every version I've seen /has/ been ugly, including one which
may have been in a version of Lua. (One problem still is recognising
uses of X-macros, as there is no prefix like 'xmacro' to look for. So
the current version may well have them; I can't tell.)

> Note that the states can have comments.  You do need a backslash at the
> end of each line, and that means comments must be /* */ style, not //
> style.

I tried various combinations but not /*...*/ before the \.

> And since we have the x-macro in place, we can use it for more things.
> Why manually declare "extern void func0(void);", etc., when you can do
> it in two lines for all the functions?
>
> #define DeclareFunc(state, func) extern void func(void);
> DoStateList(DeclareFunc)

You can also ask why need the prototype. (My first big C app, I used a
script to process my code, which also generated two sets of function
prototypes: one for locals, one for exported. This applied to all define
functions not just the ones relating to enums.)

> Maybe you want a switch rather than a jump table - that could give more
> inlining opportunities, and is a common choice for the structure of
> things like simple VM's and bytecode interpreters:
>
> #define SwitchEntry(state, func) case state : func(); break;
> void jump(enum States s) {
>     switch (s) {
>         DoStateList(SwitchEntry);
>     }
> }
>

That's an interesting use. But rather limited as it is, if it only
contains a function call; a table of functions is better. Here you'd
want to capture the generated output, and use that as a framework to
populate with manual code later on.

>>
>> With my feature, it is merely this:
>>
>>      global enumdata []ref void jumptable =
>>          (state1, func1),        # comment 1
>>          (state2, func2),
>>          (state3, func3),        # comment 3
>>          (state4, func4),
>>      end
>>
>
> That is an very niche and very limited use-case.  Did you seriously add
> a special feature to your language based on one example in one stack
> overflow question?

It's not limited at all. I use it very, very extensively. Virtually all
of my enums are written in this form, as most will at least have
associated names, if not other related data.

I rarely use bare enums. By contrast, most C source code uses bare enum
lists; there is very little use of X-macros.

I wonder if that would be different if they were a built-in,
easier-to-use feature?

> X macros are just an imaginative way to use a
> standard feature of C (and C++), giving vastly more flexibility than
> your single-use language feature.  I have difficulty seeing how it was
> worth the effort putting that feature in your tools.

That 'feature' used to done with an external script, with input coming
from text files. Putting it into the language added only one 130-line
function, and was superior and much tidier.

> Let's try a more advanced example.

>
> #define REMOVE_COMMAS_(_1, _2, _3, _4, _5, _6, _7, _8, ...) \
>     _1 _2 _3 _4 _5 _6 _7 _8
> #define REMOVE_COMMAS(...) REMOVE_COMMAS_(__VA_ARGS__, ,,,,,,,,)

<snip>

I'm sorry, but this where people get crazy with macros.

It's not just x-macros anymore, but just macros.

(Here, you will appreciate having one simple dedicated feature that you
KNOW does one thing: declare parallel enums/arrays, or arrays/arrays, in
table form.)

If I have time, I will figure out what your code is meant to do later
(it has some functions that need to be added before I can run it to see
what it does).

Then I will post a more readable version.

.... OK, I had a look. I think it is good example of using macros
ingeniously, but a poor example of code as it looks terrible. I think
far from drawing things together, it looks all over the place.

I tweaked your version into a runnable program, which took 66 lines of
code. Then I took the expanded, non-macro version and tidied it up; it
was 45 lines and far more readable.

I doubt there would be that much savings in vertical space if scaled up
to a lot more commands.

It's hard to offer alternatives, since the task is unclear (using two
levels of handler code).

But, in my stuff this sort of thing typically makes use of function
reflection. So given a command "show", I can scan function names for one
called "cmd_show", but this tends to be done in a setup step that
populates a table.

The associated help text is harder; two features that might have helped
(function metadata strings and docstrings) I used to have, but have
since dropped.

However there are lots of alternatives that still be clearer than your
example (one more is given below).

> Now, some of that is messy - no doubts there.  Some things could have
> been a lot easier if C macros were more powerful,

This is the danger - piling on even more features to a language already
ten times harder to code in that C.

If you're going to be adding features, how about fixing the main language?

> with features such as
> recursion or neater handling of variadic packs.  Macro names scoped
> within functions would also make it better.  So there's plenty of room
> for a new language to make things better than C.

> But what do we get out of this?  We have all our commands defined in one
> list, with the textual name of the command, the parameters, and a help
> text.  You can't get things out of sync - if you add a command, or
> change parameters, the help function, the declarations, and the
> dispatcher all adapt automatically.

If you adopted enums to represent commands, things can stay in sync too
(using my dynamic language so no types):

enumdata cmdnames, cmdhelp, cmdhandlers =
(showcmd, "show", "show help", cmd_show),
...

Look up a command in 'cmdnames[]'; if found this can be used to index
'cmdhelp[]' and 'cmdhandlers[]'. Each handler function is conventional.

> You might not think this is a good way to structure your source code.
> There are many possibilities, including more manual work, or more
> run-time work.  You could use an external code generator.  You could use
> a language with much better reflection capabilities (like Python).  But
> this is something you can do, today, in plain C, and it shows that
> x-macros can do vastly more than declare an enumeration and a table of
> pointers.

It simply highlights my point that /because/ C can offer such untidy,
half-way solutions, it is less likely that anyone is going to touch the
main language.

>
> Now, if your language had powerful reflection and metaprogramming
> features, along with compile-time execution, so that this kind of thing
> could be done within the language without text-based macros, then I
> would happily agree that it has better features.  Perhaps the way to do
> that would be to integrate your interpreted language in your compiler.

I can tell you that my 'mcc' compiler had some trouble with those macros
(but it seemed OK if I preprocessed it first then compiled that). I
don't relish going to back to my CPP 7 years on. So any solution that
doesn't stress it is preferable!

> There is a marvellous tool that might help you here - it's called "the
> internet".

That's great; I can finally learn Chinese too!

Meanwhile in these 49 numbers you will find next week's winning lottery
numbers: 1 2 3 ... 49.

> So the problem is your compiler, not other peoples' code?  You think

With such a project you are forced to delve more deeply into other
people's source codes and headers than most. It can be revealing.

>> That doesn't work in inline assembly.
>>
>
> So that's a limitation of your tools.

Invoking a function from assembly involves a sequence of instructions.

David Brown <david.brown@hesbynett.no> writes:
> On 02/01/2024 21:24, Bart wrote:
[...]
>> The X-macro solution was this, adapted from the first answer here
>> (https://stackoverflow.com/questions/6635851/real-world-use-of-x-macros); assume those functions are in scope:
>> -------
>> #define STATE_TABLE \
>>         ENTRY(STATE0, func0) \
>>         ENTRY(STATE1, func1) \
>>         ENTRY(STATE2, func2) \
>>         ENTRY(STATE3, func3) \
>> enum
>> {
>> #define ENTRY(a,b) a,
>>     STATE_TABLE
>> #undef ENTRY
>>     NUM_STATES
>> };
>> void* jumptable[NUM_STATES] =
>> {
>> #define ENTRY(a,b) b,
>>     STATE_TABLE
>> #undef ENTRY
>> };
>> -------
>
> (Why did you change the type from "p_func_t" to "void*" ? Was it just
> to annoy myself and other C programmers with a pointless and
> constraint-violating cast of a function pointer to "void*" ? Just add
> a suitable typedef - "typedef void(*p_func_t)(void);" )

What constraint does it violate? And what cast are you referring to?

[...]

>> But even 1/3 through I decided that it was impossible.
>> In 2017 when I created my CPP, many compilers would give different
>> results with various edge cases of macros. Which were right and
>> which were wrong? You'd think there'd be a definitive reference for
>> it.
>> Here's an example I've just found:
>>  #include <stdio.h>
>>  int main(void) {
>>   #define FOO
>>      #define BAR defined(FOO)
>>      #if BAR
>>          puts("BAR");
>>      #else
>>          puts("FOO");
>>      #endif
>>  }
>> Most compilers will display BAR; MSVC I think is the only one
>> showing FOO. (Some smaller compilers I tried on godbolt.org failed
>> to compile it.)
>> Mine showed BAR (obviously!)
>>
>
> So MSVC has a bug. Report it if you like.

Not necessarily. With clang, I get:

$ clang c.c -o c && ./c
c.c:5:5: warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined]
#if BAR
^
c.c:4:13: note: expanded from macro 'BAR'
#define BAR defined(FOO)
^
1 warning generated.
BAR

I haven't taken the time to convince myself that clang is correct, but
see N1570 6.10.1p4.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 03/01/2024 19:16, David Brown wrote:
> On 03/01/2024 18:14, Bart wrote:

>> How do you know whether I'm exaggerating or not? There have surely
>> been many millions of people who've programmed in C over the years.
>>
>
> And how many of them define or use such a macro?  Some, certainly, but
> not all.  I can't say I have ever had one in my code as far as I
> remember.  Occasionally I find it convenient to calculate the size of an
> existing array, but I'll just write it manually as an expression (like
> Scott seems to do).

So writing the same long identifier twice? And hoping there's no typo in
one? Because sizeof(A)/sizeof(B[0]) would be legal code when both A and
B are arrays.

(I already know your counter-argument: what stops someone writing
LENGTH(B) instead of LENGTH(A) anyway. Well, writing it twice gives two
opportunities to get it wrong!)

> Generally if I need the size of an array, I already
> know it - I can use the same "no_of_samples" (or whatever) constant I
> used when defining the array in the first place.

This is my A/B/N argument below. Maybe 'no_of_samples' is used as the
dimension for more than one array.

>> And a large proportion may have needed the length of an array whose
>> dimensions are not set by a constant, but by the number of data
>> elements provided.
>
> I have no basis to guess whether this proportion is large or small.  I
> don't imagine you do either.

Well, here is an extract from sqlite3.c:

/*
** A convenience macro that returns the number of elements in
** an array.
*/
#define ArraySize(X) ((int)(sizeof(X)/sizeof(X[0])))

They considered it worth having. Here's another from SDL2:

/**
* The number of elements in an array.
*/
#define SDL_arraysize(array) (sizeof(array)/sizeof(array[0]))

I didn't see one in TCC sources; they have stuff like this instead:

for(i = 0; i < sizeof(reg_saved)/sizeof(reg_saved[0]); i++) {

A loop that I would write (in 1-based form), as:

for i to reg_saved.len do

I write 'i' once, not three times; and 'reg_saved' once, not twice.

My view remains that C could do with a standardised macro, or a built-in
feature like the lengthof() extension I demonstrated.

>> (Even in the former case, if you have int A[N] and B[N], I think it is
>> better to have 'LENGTH(A)' within the subsequent code, rather than a
>> bare 'N' which could mean anything: is it the length or A, B, or does
>> it mean N by itself? What happens if you change it to A[M]?)
>
> The trick is not to use single letter identifiers when you want their
> meaning to be clear.

That doesn't affect my point. You still can't tell whether N or anything
longer refers to the length of the first or second array. Including the
name of the thing you're taking the length of is useful redundancy.

> I would not object to there being a standard C macro for finding the
> size of an array.  But I think it would be out of character for the
> standard library.

It's in character for C to define a chunk of the language via the
standard library. That doesn't appeal to me, it is very crude aspect of
the language, and also makes basic language features optional: they
don't exist until specifically enabled.

> It would make more sense if the language had more
> support for arrays and allowing them as values, parameters, and in
> expressions - then a standard "size" feature would be expected.

I can't see how that effects anything. If you have:

T A[] = {...};

then it always makes sense to have a direct way of getting the number of
elements in A without resorting to those measures demonstrated above.

Bart <bc@freeuk.cm> writes:
>On 03/01/2024 19:16, David Brown wrote:
>> On 03/01/2024 18:14, Bart wrote:
>
>>> How do you know whether I'm exaggerating or not? There have surely
>>> been many millions of people who've programmed in C over the years.
>>>
>>
>> And how many of them define or use such a macro?  Some, certainly, but
>> not all.  I can't say I have ever had one in my code as far as I
>> remember.  Occasionally I find it convenient to calculate the size of an
>> existing array, but I'll just write it manually as an expression (like
>> Scott seems to do).
>
>So writing the same long identifier twice?

Yes. Good editors mean you don't need to type it
twice (ywllp).

>And hoping there's no typo in one?

If there's a typo, the compiler will note it and I'll
fix it. But, see above.

>
Because sizeof(A)/sizeof(B[0]) would be legal code when both A and
>B are arrays.

Good thing I don't use single letter identifiers.

On 04/01/2024 01:57, Scott Lurndal wrote:
> Bart <bc@freeuk.cm> writes:
>> On 03/01/2024 19:16, David Brown wrote:
>>> On 03/01/2024 18:14, Bart wrote:
>>
>>>> How do you know whether I'm exaggerating or not? There have surely
>>>> been many millions of people who've programmed in C over the years.
>>>>
>>>
>>> And how many of them define or use such a macro?  Some, certainly, but
>>> not all.  I can't say I have ever had one in my code as far as I
>>> remember.  Occasionally I find it convenient to calculate the size of an
>>> existing array, but I'll just write it manually as an expression (like
>>> Scott seems to do).
>>
>> So writing the same long identifier twice?
>
> Yes. Good editors mean you don't need to type it
> twice (ywllp).
>
>> And hoping there's no typo in one?
>
> If there's a typo, the compiler will note it and I'll
> fix it. But, see above.
>
>>
> Because sizeof(A)/sizeof(B[0]) would be legal code when both A and
>> B are arrays.
>
> Good thing I don't use single letter identifiers.
>

What are you, 5 years old?

A and B are placeholders for arbitrary identifiers of any length.

How about if I change my remark to:

"Because
sizeof(pentium_msr_passthrough_with_knobs_on)/sizeof(k6_msr_passthrough_with_knobs_on)
would be legal code when both pentium_msr_passthrough_with_knobs_on and
k6_msr_passthrough_with_knobs_on are arrays."

You get it now?

But you're just winding me up aren't you?

On 03/01/2024 20:57, Kaz Kylheku wrote:
> On 2024-01-03, David Brown <david.brown@hesbynett.no> wrote:
>> On 03/01/2024 18:14, Bart wrote:
>>> On 03/01/2024 15:32, Scott Lurndal wrote:
>>>> Bart <bc@freeuk.cm> writes:
>>>>> On 02/01/2024 23:24, tTh wrote:
>>>>>> On 1/2/24 21:24, Bart wrote:
>>>>>>>
>>>>>>> You missed my point. Take a tiny feature like being able to easily get
>>>>>>> the size of a fixed-length array. You commonly see macro like this:
>>>>>>>
>>>>>>>      #define LENGTH(a) (sizeof(a)/size(a[0]))
>>>>>>
>>>>>>      And why is that bad? That's a real question.
>>>>>
>>>>> Where do I start?
>>>>>
>>>>> * Why is it necessary for a million programmers to each come up with
>>>>>    their own solutions for something so basic? Eg. they will all use
>>>>>    diferent names.
>>>>
>>>> Why is it necessary to exaggerate?
>>>
>>> How do you know whether I'm exaggerating or not? There have surely been
>>> many millions of people who've programmed in C over the years.
>>>
>>
>> And how many of them define or use such a macro? Some, certainly, but
>> not all.
>
> I've seen it a lot. If it didn't have issues, it would be an excellent
> inclusion in <stddef.h>, along with offsetof(type, member) and such.
>
> Macros with issues should not be standardized though. For instance min
> and max macros appear regularly in C programs, but feature multiple
> argument evaluation.

Arguably the "array size" macros /do/ have issues. Either they are too
easy to use accidentally with pointers instead of arrays, or they cause
compile-time errors for arrays of size one (due to protection against
use with pointers), or they rely on compiler extensions to protect
against use on pointers.

In one way, that would make it a better choice to have "array_size" in
the standard - the standard could simply require that applying
"array_size" to a pointer is a constraint error, and it's up to the
implementation to figure out what compiler magic is needed to make that
work. (The "offsetof" macro is similar - it can't be implemented in
completely portable, compliant and fully defined behaviour C code.)

However, I think it is all too late for that. It certainly can't be
added to <stddef.h> or <stdlib.h> - what would you call it without
conflicting with existing names in existing code? You'd have to put it
in its own header, and it would all be a huge amount of work and fuss
for something that no one would ever use - everyone who wants such a
macro can write one faster themselves than it takes to type "#include
<stdarraysize.h>".

>
> For these kinds of things, it's better to wait until the language
> develops a good solution. min and max want to be type-generic inline
> functions. I think that this is doable in C with _Generic. In the
> April 2023 draft, I don't see any min functions other than fminf,
> fmin and fminl, which are float, double and long double. No generic
> min and max are mentioned for <tgmath.h>
>
> There are probably too many combinations to handle; you need
> two levels of _Generic selection, each switching on a number of integer
> and floating-point types. (There being reams and reams of templates
> doesn't stop C++, though.)
>

C++ has three major differences for this kind of thing. One is that
they have a good namespace for new standard library functions, hugely
reducing the risk and cost of adding functions. They have arrays as
"real" types - useable as values and with strong typing, eliminating the
complication of decaying to pointers to the first element. (If you are
programming in C++ and are working with fixed size arrays, std::array<>
is often a better choice than C-style arrays. And if you are using
dynamic arrays, std::vector<> is probably best.) And C++ already has an
advanced template system that is far beyond what you can do with C11's
_Generic.

So I think you are partially right - I agree it is better not to try to
have this kind of thing in the standard library without better language
support for metaprogramming and for more solid arrays, but I don't think
C will or should gain such features. I think C should be considered
"mostly complete" - some improvements are helpful, but not major
language changes. The whole point of C is its stability as a language,
and if a programmer wants more, it's better to choose a different
language such as C++ or one of the "better than C but less complicated
than C++" options such as D or Rust.

> For counting the elements in an array, we really want a sizeof-like
> keyword, which takes a parenthesized type or expression. That expression
> is constrained to be of array type.
>
> (Might it be possible with _Generic to detect that we have an operand
> which is an "array of anything"? I'm guessing not.)
>

On 04/01/2024 00:48, Bart wrote:
> On 03/01/2024 19:16, David Brown wrote:
>> On 03/01/2024 18:14, Bart wrote:
>
>>> How do you know whether I'm exaggerating or not? There have surely
>>> been many millions of people who've programmed in C over the years.
>>>
>>
>> And how many of them define or use such a macro?  Some, certainly, but
>> not all.  I can't say I have ever had one in my code as far as I
>> remember.  Occasionally I find it convenient to calculate the size of
>> an existing array, but I'll just write it manually as an expression
>> (like Scott seems to do).
>
> So writing the same long identifier twice? And hoping there's no typo in
> one? Because sizeof(A)/sizeof(B[0]) would be legal code when both A and
> B are arrays.
>

If you have difficulty typing out the same identifier twice, then you
have picked a poor name for the identifier! The whole point of
identifiers is to identify things - you give the thing a name, so that
you can refer to it later by that same name and know you are referring
to the same thing. If find this difficult when using the same array
identifier twice in one expression, then you have vastly bigger problems
with your coding than getting the size of an array.

> (I already know your counter-argument: what stops someone writing
> LENGTH(B) instead of LENGTH(A) anyway. Well, writing it twice gives two
> opportunities to get it wrong!)

No, that was never in my thoughts as a counter-argument.

>
>> Generally if I need the size of an array, I already know it - I can
>> use the same "no_of_samples" (or whatever) constant I used when
>> defining the array in the first place.
>
> This is my A/B/N argument below. Maybe 'no_of_samples' is used as the
> dimension for more than one array.

Yes, maybe it is. But I know the size of the arrays I use. If I don't
know, I look at the definition to see. I don't code blindly.

>
>>> And a large proportion may have needed the length of an array whose
>>> dimensions are not set by a constant, but by the number of data
>>> elements provided.
>>
>> I have no basis to guess whether this proportion is large or small.  I
>> don't imagine you do either.
>
> Well, here is an extract from sqlite3.c:

I didn't write sqlite3.c. I am not responsible for the choices of
identifiers, or coding style, or macro usage, or anything else in it. I
am telling you why /I/ don't need or use any kind of "array_size" macro.
Other people may write their code differently.

On 03/01/2024 22:42, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 02/01/2024 21:24, Bart wrote:
> [...]
>>> The X-macro solution was this, adapted from the first answer here
>>> (https://stackoverflow.com/questions/6635851/real-world-use-of-x-macros); assume those functions are in scope:
>>> -------
>>> #define STATE_TABLE \
>>>         ENTRY(STATE0, func0) \
>>>         ENTRY(STATE1, func1) \
>>>         ENTRY(STATE2, func2) \
>>>         ENTRY(STATE3, func3) \
>>> enum
>>> {
>>> #define ENTRY(a,b) a,
>>>     STATE_TABLE
>>> #undef ENTRY
>>>     NUM_STATES
>>> };
>>> void* jumptable[NUM_STATES] =
>>> {
>>> #define ENTRY(a,b) b,
>>>     STATE_TABLE
>>> #undef ENTRY
>>> };
>>> -------
>>
>> (Why did you change the type from "p_func_t" to "void*" ? Was it just
>> to annoy myself and other C programmers with a pointless and
>> constraint-violating cast of a function pointer to "void*" ? Just add
>> a suitable typedef - "typedef void(*p_func_t)(void);" )
>
> What constraint does it violate? And what cast are you referring to?

I believe the initialisation follows the requirements for simple
assignment, and function pointers are not compatible with void*. Bart
(for reasons understood only by him) uses void* pointers when he wants
generic function pointers. The stack overflow link uses "p_func_t",
which is a function pointer typedef.

On 04/01/2024 08:55, David Brown wrote:
> On 04/01/2024 00:48, Bart wrote:
>> On 03/01/2024 19:16, David Brown wrote:
>>> On 03/01/2024 18:14, Bart wrote:
>>
>>>> How do you know whether I'm exaggerating or not? There have surely
>>>> been many millions of people who've programmed in C over the years.
>>>>
>>>
>>> And how many of them define or use such a macro?  Some, certainly,
>>> but not all.  I can't say I have ever had one in my code as far as I
>>> remember.  Occasionally I find it convenient to calculate the size of
>>> an existing array, but I'll just write it manually as an expression
>>> (like Scott seems to do).
>>
>> So writing the same long identifier twice? And hoping there's no typo
>> in one? Because sizeof(A)/sizeof(B[0]) would be legal code when both A
>> and B are arrays.
>>
>
> If you have difficulty typing out the same identifier twice, then you
> have picked a poor name for the identifier!  The whole point of
> identifiers is to identify things - you give the thing a name, so that
> you can refer to it later by that same name and know you are referring
> to the same thing.  If find this difficult when using the same array
> identifier twice in one expression, then you have vastly bigger problems
> with your coding than getting the size of an array.

You can make typos. You can accidentally use the name of some other
similarly named but unrelated variable.

You really can't understand that the opportunities for such errors
increases with the amount of code you have to write? As well as the
amount of obscuring clutter?

It's not just writing two long identifiers instead of one; here those
additionally have to match.

> Yes, maybe it is.  But I know the size of the arrays I use.  If I don't
> know, I look at the definition to see.  I don't code blindly.

You have this (and please don't complain about these terse names; a real
program will be much larger, much busier, and have much longer names):

enum {N = 10;}
int A[N];
int B[N];
int C[N];

for (i = 0; i<N; ++N)
... Do something with A ...

for (i = 0; i<N; ++N)
... Do something with B ...

(I will leave the typos I've just noticed. Bloody stupid C for loops...)

Later I change A[N] to be A[M] as I said a few posts ago. Now you have
to go through the program looking for things that reference the length of A.

But you only have N; you can't tell from that itself whether it I
specifically used as the length of A or not. The job is harder. Now
consider this version:

for (i = 0; i<LENGTH(A); ++i)
... Do something with A ...

for (i = 0; i<LENGTH(B); ++i)
... Do something with B ...

Which version will be easier to update? (Hint: this one doesn't need any
changes.)

>> Well, here is an extract from sqlite3.c:
>
> I didn't write sqlite3.c.  I am not responsible for the choices of
> identifiers, or coding style, or macro usage, or anything else in it.  I
> am telling you why /I/ don't need or use any kind of "array_size" macro.
>  Other people may write their code differently.

So in you code, if I see:

sizeof(expr1)/sizeof(expr2)

what I am supposed to deduce from that? That it /might/ be an idiom for
getting the number of elements in array? Then it might involving looking
in more detail to see that expr2 is really just expr1[0].

On the other hand, if I see:

ArraySize(expr)

then you are expressing what your intentions are more clearly. Moreover,
with that term now being more compact, I can concentrate more on what
goes before and after it.

BTW here is anoher macro, this time from a file called gcc.c (an old
amalgamation):

#define ARRAY_SIZE(a) (sizeof (a) / sizeof ((a)[0]))

*Everybody* is at it, but that doesn't count because /you/ don't do it?
It is used like this:

for (i = 0; i < ARRAY_SIZE (conversion_tab); i++)
if (sysctl (mib, ARRAY_SIZE (mib), &physmem, &len, NULL, 0) == 0
b < (operator_array + ARRAY_SIZE (operator_array));
size_t n = ARRAY_SIZE (builtin_array);

which would otherwise look like so:

for (i = 0; i < sizeof(conversion_tab)/sizeof(conversion_tab); i++)
if (sysctl (mib, sizeof(mib)/sizeof(mib[0]), &physmem, &len, NULL,
0) == 0
b < (operator_array +
sizeof(operator_array)/sizeof(operator_array)[0]);
size_t n = sizeof(builtin_array)/sizeof(builtin_array[0]);

On 04/01/2024 11:46, David Brown wrote:
> On 03/01/2024 22:42, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 02/01/2024 21:24, Bart wrote:
>> [...]
>>>> The X-macro solution was this, adapted from the first answer here
>>>> (https://stackoverflow.com/questions/6635851/real-world-use-of-x-macros); assume those functions are in scope:
>>>> -------
>>>> #define STATE_TABLE \
>>>>           ENTRY(STATE0, func0) \
>>>>           ENTRY(STATE1, func1) \
>>>>           ENTRY(STATE2, func2) \
>>>>           ENTRY(STATE3, func3) \
>>>> enum
>>>> {
>>>> #define ENTRY(a,b) a,
>>>>       STATE_TABLE
>>>> #undef ENTRY
>>>>       NUM_STATES
>>>> };
>>>> void* jumptable[NUM_STATES] =
>>>> {
>>>> #define ENTRY(a,b) b,
>>>>       STATE_TABLE
>>>> #undef ENTRY
>>>> };
>>>> -------
>>>
>>> (Why did you change the type from "p_func_t" to "void*" ?  Was it just
>>> to annoy myself and other C programmers with a pointless and
>>> constraint-violating cast of a function pointer to "void*" ?  Just add
>>> a suitable typedef - "typedef void(*p_func_t)(void);" )
>>
>> What constraint does it violate?  And what cast are you referring to?
>
> I believe the initialisation follows the requirements for simple
> assignment, and function pointers are not compatible with void*.  Bart
> (for reasons understood only by him) uses void* pointers when he wants
> generic function pointers.  The stack overflow link uses "p_func_t",
> which is a function pointer typedef.
>
>

The SO link didn't define p_func_t that I could see. I changed it to
void* to avoid the bother of doing so when testing, and to avoid having
to include that in my example that would be a distraction.

On 03/01/2024 22:32, Bart wrote:
> On 03/01/2024 16:41, David Brown wrote:
>> On 02/01/2024 21:24, Bart wrote:
>
>> I personally like to use a slightly different syntax, but that's just
>> detail and style choice.
>>
>>
>> #define DoStateList(DO) \
>>          DO(state0, func0) /* Comment */ \
>>          DO(state1, func1) \
>>          DO(state2, func2) \
>>          DO(state3, func3) \
>>
>> #define GetState(state, func) state,
>> #define GetFunc(state, func) func,
>> #define Counter(state, func) +1
>>
>> enum { num_of_states = DoStateList(Counter) };
>>
>> enum States {
>>      DoStateList(GetState)
>> };
>>
>> p_func_t jump_table[] = {
>>      DoStateList(GetFunc)
>> };
>>
>>
>
> I admit that your version is cleaner than other versions of X-macros
> I've come across. I can almost even understand it.

I also think it is better this way. But I don't believe you can
/almost/ understand it - I believe you can understand it perfectly well.
(You might not like it, or see it as useful, but that's a matter of
preference and opinion.)

>
> But nearly every version I've seen /has/ been ugly, including one which
> may have been in a version of Lua. (One problem still is recognising
> uses of X-macros, as there is no prefix like 'xmacro' to look for. So
> the current version may well have them; I can't tell.)

"x-macro" is not a well-defined term. It is simply the general
technique of making a list of some sort in a macro, and using it several
times later.

>
>> Note that the states can have comments.  You do need a backslash at
>> the end of each line, and that means comments must be /* */ style, not
>> // style.
>
> I tried various combinations but not /*...*/ before the \.
>

You can use /* */ comments in all sorts of places - they get treated as
white space.

>> And since we have the x-macro in place, we can use it for more things.
>> Why manually declare "extern void func0(void);", etc., when you can do
>> it in two lines for all the functions?
>>
>> #define DeclareFunc(state, func) extern void func(void);
>> DoStateList(DeclareFunc)
>
> You can also ask why need the prototype.

You don't mean "prototype" here, you mean "declaration". A function
prototype in C gives the number and types of the parameters, the name of
the function, and the return type, and can be given as a stand-alone
declaration or along with the function definition. You are asking why
we need stand-alone declarations here.

The easy answer is we need them because C requires declarations before
you can call a function or take its address. The next question is why
does C need that for functions that are defined later in the same source
file, and the answer then is that it avoids needing an extra pass in the
compiler. I would not expect newer languages to take such
considerations and need declarations (other than for imported functions,
and presumably a more modern language would use some kind of module
mechanism there).

> (My first big C app, I used a
> script to process my code, which also generated two sets of function
> prototypes: one for locals, one for exported. This applied to all define
> functions not just the ones relating to enums.)
>
>> Maybe you want a switch rather than a jump table - that could give
>> more inlining opportunities, and is a common choice for the structure
>> of things like simple VM's and bytecode interpreters:
>>
>> #define SwitchEntry(state, func) case state : func(); break;
>> void jump(enum States s) {
>>      switch (s) {
>>          DoStateList(SwitchEntry);
>>      }
>> }
>>
>
> That's an interesting use. But rather limited as it is, if it only
> contains a function call; a table of functions is better. Here you'd
> want to capture the generated output, and use that as a framework to
> populate with manual code later on.
>

No, the "manual code" goes in the handler functions.

And no, a jump table is /not/ better - the switch is better in most ways:

1. The compiler can always implement the switch with a jump table, if
that is the most efficient method. It can choose many other ways to do
it too.

2. When the compiler can see the source of the functions (they are
defined in the same file, or you are using LTO or other whole-program
optimisation, as you do if you need top efficiency), the code can be
generated inline in the switch. That can mean reducing function call
overheads, sharing code, merging in constants, etc.

3. If the "jump" function is called in a way that the compiler can see
the parameter used, it can inline the called handler function in the
code that calls "jump", again leading to many possible optimisations.

4. Call tree analysis does not work (or works very poorly) over function
pointers. If you can avoid function pointers, programmers, compilers,
documentation tools, and static analysis tools have a vastly better
picture of the possible code flow. This lets you get high-level
overviews, trace code flow backwards, analyse stack usage, etc. It
makes debugging and code analysis much easier.

>
>>>
>>> With my feature, it is merely this:
>>>
>>>      global enumdata []ref void jumptable =
>>>          (state1, func1),        # comment 1
>>>          (state2, func2),
>>>          (state3, func3),        # comment 3
>>>          (state4, func4),
>>>      end
>>>
>>
>> That is an very niche and very limited use-case.  Did you seriously
>> add a special feature to your language based on one example in one
>> stack overflow question?
>
> It's not limited at all. I use it very, very extensively. Virtually all
> of my enums are written in this form, as most will at least have
> associated names, if not other related data.
>
> I rarely use bare enums. By contrast, most C source code uses bare enum
> lists; there is very little use of X-macros.
>

I use enumerated types a lot, but it's rare that it would make sense in
my code to associate them with anything (names, data, actions) at that
point in the code.

> I wonder if that would be different if they were a built-in,
> easier-to-use feature?

It is possible - certainly familiarity will influence how much a
technique is used. But lots of C programmers are unaware of a good deal
of language features and standard library tools, so it is no guarantee.

Remember, the choice of features for /your/ language and library are
determined almost exclusively by what /you/ want, for the kinds of
programs /you/ write. That is the advantage of personal languages, but
it also means that comparisons of features popularity with mainstream
languages are almost completely pointless. They are of even less
validity than looking at the features a single C programmer (such as
myself) uses, or what is used in a particular C program, when trying to
judge the popularity of C features.

>
>> X macros are just an imaginative way to use a standard feature of C
>> (and C++), giving vastly more flexibility than your single-use
>> language feature.  I have difficulty seeing how it was worth the
>> effort putting that feature in your tools.
>
> That 'feature' used to done with an external script, with input coming
> from text files. Putting it into the language added only one 130-line
> function, and was superior and much tidier.
>

It's neater if you don't need an external tool, yes.

>
>> Let's try a more advanced example.
>
>>
>> #define REMOVE_COMMAS_(_1, _2, _3, _4, _5, _6, _7, _8, ...) \
>>      _1 _2 _3 _4 _5 _6 _7 _8
>> #define REMOVE_COMMAS(...) REMOVE_COMMAS_(__VA_ARGS__, ,,,,,,,,)
>
>
> <snip>
>
> I'm sorry, but this where people get crazy with macros.
>
> It's not just x-macros anymore, but just macros.

I fully appreciate that it requires more effort to understand such
macros, and their use is not to everyone's taste. People who use these
things generally have a collection of macros they like in a header, and
use them as needed without worrying about the details. Mostly the
macros will come from elsewhere. Actually, all that sounds just like
programming as usual - it's what programmers do all the time, in any
language. Very, very few programmers limit themselves to only ever
using code they write themselves or understand themselves.

On 04/01/2024 13:15, Bart wrote:
> On 04/01/2024 08:55, David Brown wrote:
>> On 04/01/2024 00:48, Bart wrote:
>>> On 03/01/2024 19:16, David Brown wrote:
>>>> On 03/01/2024 18:14, Bart wrote:
>>>
>>>>> How do you know whether I'm exaggerating or not? There have surely
>>>>> been many millions of people who've programmed in C over the years.
>>>>>
>>>>
>>>> And how many of them define or use such a macro?  Some, certainly,
>>>> but not all.  I can't say I have ever had one in my code as far as I
>>>> remember.  Occasionally I find it convenient to calculate the size
>>>> of an existing array, but I'll just write it manually as an
>>>> expression (like Scott seems to do).
>>>
>>> So writing the same long identifier twice? And hoping there's no typo
>>> in one? Because sizeof(A)/sizeof(B[0]) would be legal code when both
>>> A and B are arrays.
>>>
>>
>> If you have difficulty typing out the same identifier twice, then you
>> have picked a poor name for the identifier!  The whole point of
>> identifiers is to identify things - you give the thing a name, so that
>> you can refer to it later by that same name and know you are referring
>> to the same thing.  If find this difficult when using the same array
>> identifier twice in one expression, then you have vastly bigger
>> problems with your coding than getting the size of an array.
>
> You can make typos. You can accidentally use the name of some other
> similarly named but unrelated variable.
>
> You really can't understand that the opportunities for such errors
> increases with the amount of code you have to write? As well as the
> amount of obscuring clutter?
>
> It's not just writing two long identifiers instead of one; here those
> additionally have to match.
>
>
>> Yes, maybe it is.  But I know the size of the arrays I use.  If I
>> don't know, I look at the definition to see.  I don't code blindly.
>
> You have this (and please don't complain about these terse names; a real
> program will be much larger, much busier, and have much longer names):
>
>    enum {N = 10;}
>    int A[N];
>    int B[N];
>    int C[N];
>
>    for (i = 0; i<N; ++N)
>      ... Do something with A ...
>
>    for (i = 0; i<N; ++N)
>      ... Do something with B ...
>
> (I will leave the typos I've just noticed. Bloody stupid C for loops...)
>
> Later I change A[N] to be A[M] as I said a few posts ago. Now you have
> to go through the program looking for things that reference the length
> of A.
>
> But you only have N; you can't tell from that itself whether it I
> specifically used as the length of A or not. The job is harder. Now
> consider this version:
>
>    for (i = 0; i<LENGTH(A); ++i)
>      ... Do something with A ...
>
>    for (i = 0; i<LENGTH(B); ++i)
>      ... Do something with B ...
>
> Which version will be easier to update? (Hint: this one doesn't need any
> changes.)
>

That is not a problem I would come across in my code. If, for example,
B and C hang together tightly while A might be different, then I would
be defining them as :

enum { N_A = 10, N_BC = 10 };

int A[N_A];
int B[N_BC];
int C[N_BC];

I wouldn't use the same size constant for inherently separate things
simply because they happened to have the same number of items!

And if I later decided that B and C did not belong tightly coupled after
all, I'd change it to:

enum { N_A = 10, N_B = 10, N_C = 10 };

int A[N_A];
int B[N_B];
int C[N_C];

I would expect to have to change the usage of the arrays in conjunction
with the decoupling change, so changing the later for-loops is needed
anyway. And if I forgot, the compiler would remind me when the use of
N_BC fails to compile - forcing me to double-check the usage. I'd
rather be forced to change the later loops, than have them compile
silently after such changes, since it is likely that they will need
other modification.

>
>
>>> Well, here is an extract from sqlite3.c:
>>
>> I didn't write sqlite3.c.  I am not responsible for the choices of
>> identifiers, or coding style, or macro usage, or anything else in it.
>> I am telling you why /I/ don't need or use any kind of "array_size"
>> macro.   Other people may write their code differently.
>
>
> So in you code, if I see:
>
>    sizeof(expr1)/sizeof(expr2)
>
> what I am supposed to deduce from that? That it /might/ be an idiom for
> getting the number of elements in array? Then it might involving looking
> in more detail to see that expr2 is really just expr1[0].
>

You are supposed to deduce that I did not write it. I would never use
such bad spacing conventions :-)

But if it is not clear and obvious what is going on, then the code is bad.

> On the other hand, if I see:
>
>    ArraySize(expr)
>
> then you are expressing what your intentions are more clearly.

That is assuming you know whether ArraySize returns the number of
elements in the array, or its size in bytes.

But if you prefer a macro like this to alternatives, that's fine. I can
only tell you what /I/ prefer to do.

Bart <bc@freeuk.cm> writes:
>On 04/01/2024 01:57, Scott Lurndal wrote:
>> Bart <bc@freeuk.cm> writes:
>>> On 03/01/2024 19:16, David Brown wrote:
>>>> On 03/01/2024 18:14, Bart wrote:
>>>
>>>>> How do you know whether I'm exaggerating or not? There have surely
>>>>> been many millions of people who've programmed in C over the years.
>>>>>
>>>>
>>>> And how many of them define or use such a macro?  Some, certainly, but
>>>> not all.  I can't say I have ever had one in my code as far as I
>>>> remember.  Occasionally I find it convenient to calculate the size of an
>>>> existing array, but I'll just write it manually as an expression (like
>>>> Scott seems to do).
>>>
>>> So writing the same long identifier twice?
>>
>> Yes. Good editors mean you don't need to type it
>> twice (ywllp).
>>
>>> And hoping there's no typo in one?
>>
>> If there's a typo, the compiler will note it and I'll
>> fix it. But, see above.
>>
>>>
>> Because sizeof(A)/sizeof(B[0]) would be legal code when both A and
>>> B are arrays.
>>
>> Good thing I don't use single letter identifiers.
>>
>
>What are you, 5 years old?
>
>A and B are placeholders for arbitrary identifiers of any length.
>
>How about if I change my remark to:
>
>"Because
>sizeof(pentium_msr_passthrough_with_knobs_on)/sizeof(k6_msr_passthrough_with_knobs_on)
>would be legal code when both pentium_msr_passthrough_with_knobs_on and
>k6_msr_passthrough_with_knobs_on are arrays."

It's pretty obvious to even the meanest programmer that code is incorrect.