On 1/4/24 06: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*.

You're right, for initialization "the same type constraints and
conversions as for simple assignment apply,". This initialization
violates those constraints. There's two options listed in 6.5.16.1p1
that might apply: since the object is a pointer, the initializer could
be a pointer to a compatible type. Since the object is, in particular, a
void*, it could be a pointer to an object type - but this initializer
doesn't qualify for either of those cases.
However, it was the cast you described as "constraint-violating", not
the initialization, and that's what's incorrect.

On 1/4/24 07:37, Bart wrote:
> 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. ...

It also didn't provide declarations for func0, func1, func2, func3, or
FuncX. From C's rules for initialization, you should have concluded that
it was a pointer to a function type that is compatible with the types of
those functions.

> ... 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.

You don't consider it distracting that void* makes it a constraint
violation, rendering the behavior of any program that uses such code
undeifined?

On 04/01/2024 17:51, James Kuyper wrote:
> On 1/4/24 07:37, Bart wrote:

>> The SO link didn't define p_func_t that I could see. ...
>
> It also didn't provide declarations for func0, func1, func2, func3, or
> FuncX. From C's rules for initialization, you should have concluded that
> it was a pointer to a function type that is compatible with the types of
> those functions.
>
>> ... 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.
>
> You don't consider it distracting that void* makes it a constraint
> violation, rendering the behavior of any program that uses such code
> undeifined?

Only to people obsessed with Standards minutiae.

I can't remember if I only did a preprocessing test, or added enough
(declarations for functions etc) to compile, but here is a version
within a working program that I've just done:

-------------
#include <stdio.h>

void func0(void){}
void func1(void){}
void func2(void){}
void func3(void){}

#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
};

int main(void) {
printf("%d\n", NUM_STATES);
printf("%d %p\n", STATE0, jumptable[STATE0]);
printf("%d %p\n", STATE1, jumptable[STATE1]);
printf("%d %p\n", STATE2, jumptable[STATE2]);
printf("%d %p\n", STATE3, jumptable[STATE3]);
} -------------

I tested it on 5 compilers and it gave the expected results. It shows
that the x-macro works, it's just unwieldy.

On 04/01/2024 16:08, Scott Lurndal wrote:
> Bart <bc@freeuk.cm> writes:
>> On 04/01/2024 01:57, Scott Lurndal wrote:

>>> 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.

Is it? How do you know? The code is valid:

--------
int pentium_msr_passthrough_with_knobs_on;
int k6_msr_passthrough_with_knobs_on;

int main(void) {
sizeof(pentium_msr_passthrough_with_knobs_on)/sizeof(k6_msr_passthrough_with_knobs_on);
} --------

This compiles fine. It is valid C. But what does it mean? Given more
suitable types for those expressions, is it an incorrect attempt to get
an array length, or something else entirely?

Using this definition of the first variable:

int pentium_msr_passthrough_with_knobs_on[13];

Then it does in fact evaluate its length, although partly by coincidence
as both base-types are 'int'.

(Now you're going to point out that it doesn't use that value; yes, we
know.)

Here's the same experiment with my language:

int pentium_msr_passthrough_with_knobs_on
int k6_msr_passthrough_with_knobs_on

proc main=
pentium_msr_passthrough_with_knobs_on.len
end

This is more transparent: it's definitely evaluating the length of that
variable, but it fails because it is not an array. If I add that '[13]'
(here it goes at the left), then it works.

Now look at the basketcase that is C's attempt. C could EASILY have had
an equivalent op that works like 'size'of'; it chose not to.

Why is everyone trying to make out that C's approach is superior when it
clearly isn't?

David Brown <david.brown@hesbynett.no> writes:
> 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.

Bart's code initializes array elements of type void* with values that
are presumably of pointer-to-function type. That is indeed a constraint
violation (one that, unfortunately, gcc doesn't even warn about with
default options).

David, your use of the word "cast" confused me. What's happening in the
code is an implicit conversion, not a cast (or it would be if that
particular implicit conversion were defined in the language, or if
you're using a non-standard C dialect that defines it).

--
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 */

Bart <bc@freeuk.cm> writes:
> On 04/01/2024 17:51, James Kuyper wrote:
>> On 1/4/24 07:37, Bart wrote:
>
>>> The SO link didn't define p_func_t that I could see. ...
>> It also didn't provide declarations for func0, func1, func2, func3,
>> or
>> FuncX. From C's rules for initialization, you should have concluded that
>> it was a pointer to a function type that is compatible with the types of
>> those functions.
>>
>>> ... 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.
>> You don't consider it distracting that void* makes it a constraint
>> violation, rendering the behavior of any program that uses such code
>> undeifined?
>
> Only to people obsessed with Standards minutiae.

I.e., concerned about correctness of C code.

> I can't remember if I only did a preprocessing test, or added enough
> (declarations for functions etc) to compile, but here is a version
> within a working program that I've just done:
>
> -------------
> #include <stdio.h>
>
> void func0(void){}
> void func1(void){}
> void func2(void){}
> void func3(void){}
>
> #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
> };
>
> int main(void) {
> printf("%d\n", NUM_STATES);
> printf("%d %p\n", STATE0, jumptable[STATE0]);
> printf("%d %p\n", STATE1, jumptable[STATE1]);
> printf("%d %p\n", STATE2, jumptable[STATE2]);
> printf("%d %p\n", STATE3, jumptable[STATE3]);
> }
> -------------
>
> I tested it on 5 compilers and it gave the expected results. It shows
> that the x-macro works, it's just unwieldy.

You didn't test it with a *conforming* C compiler. Most C compilers
are not conforming by default (which I personally consider to
be unfortunate).

On my system, both gcc and clang compile that code with no errors
or warnings, and it appears to execute correctly. But both "gcc
-pedantic" and "clang -pedantic" issue multiple warnings, and both
"gcc -pedantic-errors" and "clang -pedantic-errors" reject it.

I understand that you don't care about this, so there's no need
to repeat yourself. I'm not even saying you should care about it.
Most of us here do care about it, and I suggest you accept that.

--
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 2024-01-04, David Brown <david.brown@hesbynett.no> wrote:
> 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?

I would call it elems or something, and hide the identifier unless
a new dialect of C is being used.

E.g. in the case of gcc, it would not be revealed in <stddef.h> if
only -std=c23 is in effect; a newer dialect selection would be required.

The standard headers have been getting new identifiers, right?
Like many new functions in <math.h>.

Those are functions which have linkage, which presents an implementation
challenge on top of the declarations in the header being easy to hide.

A size operator for arrays doesn't have linkage to worry about.

--
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 04.01.2024 19:35, Bart wrote:
>
> Now look at the basketcase that is C's attempt. C could EASILY have had
> an equivalent op that works like 'size'of'; it chose not to.

You're asking for an, say, 'nof_elements(A)', where there's currently
only a 'sizeof(A)/sizeof(A[0])' existing? - Is that the whole resume
of this overly bulky subthread?

Janis

On 04/01/2024 19:55, Janis Papanagnou wrote:
> On 04.01.2024 19:35, Bart wrote:
>>
>> Now look at the basketcase that is C's attempt. C could EASILY have had
>> an equivalent op that works like 'size'of'; it chose not to.
>
> You're asking for an, say, 'nof_elements(A)', where there's currently
> only a 'sizeof(A)/sizeof(A[0])' existing? - Is that the whole resume
> of this overly bulky subthread?

Yes exactly.

If you're arguing that it is such a trivial matter that it is hardly
worth discussing, I can equally say that if it is that trivial, why
isn't it just built-in? How hard can it be?

The subthread was actually about the macro system, and this example was
one I gave where macros make it possible for every man and his dog to
create their own sloppy, incompatible workaround.

Every other app seems to provide their own version; I gave three where
so far we have ArraySize, SDL_arraysize, and ARRAY_SIZE.

You yourself have suggested 'nof_elements'. You see the problem?

I'm not actually too bothered about that (I know C is never going to
have anything that is that sensible), I'm arguing against attitudes like
yours that it doesn't matter.

My original point may have been this: suppose C's macro system didn't
exist. Would that have given enough impetus to whoever was or were
responsible for the language, to actually do it properly?

Since my conjecture was that C's macro scheme stopped it evolving normally.

On 04/01/2024 19:36, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> 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.
>
> Bart's code initializes array elements of type void* with values that
> are presumably of pointer-to-function type. That is indeed a constraint
> violation (one that, unfortunately, gcc doesn't even warn about with
> default options).
>
> David, your use of the word "cast" confused me. What's happening in the
> code is an implicit conversion, not a cast (or it would be if that
> particular implicit conversion were defined in the language, or if
> you're using a non-standard C dialect that defines it).
>

You are correct there - there was no cast in the code, so my wording was
wrong.

Bart <bc@freeuk.cm> writes:
>On 04/01/2024 16:08, Scott Lurndal wrote:
>> Bart <bc@freeuk.cm> writes:
>>> On 04/01/2024 01:57, Scott Lurndal wrote:
>
>>>> 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.
>
>Is it? How do you know? The code is valid:
>
>--------
>int pentium_msr_passthrough_with_knobs_on;
>int k6_msr_passthrough_with_knobs_on;
>
>int main(void) {
>sizeof(pentium_msr_passthrough_with_knobs_on)/sizeof(k6_msr_passthrough_with_knobs_on);
>}
>--------
>
>This compiles fine.

So what? Any programmer will see that they don't
match immediately. It is obviously wrong.

Give it up already. Propose a modification to the
C language to the standards committee. Bitching about
it is just noise.

On 2024-01-04, Scott Lurndal <scott@slp53.sl.home> wrote:
> Bart <bc@freeuk.cm> writes:
>>
>>This compiles fine.
>
> So what? Any programmer will see that they don't
> match immediately. It is obviously wrong.
>
> Give it up already. Propose a modification to the
> C language to the standards committee. Bitching about
> it is just noise.

Oh boy and isn't there a lot of it - yawn!!!!!

I admire the preserverance

On 1/4/24 13:21, Bart wrote:
> On 04/01/2024 17:51, James Kuyper wrote:
....
>> You don't consider it distracting that void* makes it a constraint
>> violation, rendering the behavior of any program that uses such code
>> undeifined?
>
> Only to people obsessed with Standards minutiae.

These "standards minutae" mean that a conforming implementation of C has
no obligation to produce any particular kind of behavior for such code.
If you don't care what kind of behavior your code has, why write a new
program? Take any existing program - whatever behavior that existing
program has, is one of the behaviors that an implementation is allowed
to produce when translating your new program. Since you've declared, by
deliberately using such code, that you don't care whether it produces
such behavior, using the existing program should be fine.

On 04/01/2024 22:07, Jim Jackson wrote:
> On 2024-01-04, Scott Lurndal <scott@slp53.sl.home> wrote:
>> Bart <bc@freeuk.cm> writes:
>>>
>>> This compiles fine.
>>
>> So what? Any programmer will see that they don't
>> match immediately. It is obviously wrong.
>>
>> Give it up already. Propose a modification to the
>> C language to the standards committee. Bitching about
>> it is just noise.
>
> Oh boy and isn't there a lot of it - yawn!!!!!
>
> I admire the preserverance

For 40 years 99% of my coding has been in a language where you just write:

A.len

instead of:

sizeof(A)/size(A[0])

So it's no skin off my nose if you prefer to do that or are happy
reinventing various workarounds.

I had wondered if things would have been any different without macros to
create those workarounds.

It looks like, probably not.

So, /I/ admire your stoicism in putting up with a badly designed
language of which this is one tiny aspect.

(Tell me, if /you/ were to design a new language, would you still
require that sizeof/sizeof business? No? Thought not!)

On 2024-01-04, Bart <bc@freeuk.cm> wrote:
> On 04/01/2024 22:07, Jim Jackson wrote:
>> On 2024-01-04, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> Bart <bc@freeuk.cm> writes:
>>>>
>>>> This compiles fine.
>>>
>>> So what? Any programmer will see that they don't
>>> match immediately. It is obviously wrong.
>>>
>>> Give it up already. Propose a modification to the
>>> C language to the standards committee. Bitching about
>>> it is just noise.
>>
>> Oh boy and isn't there a lot of it - yawn!!!!!
>>
>> I admire the preserverance
>
> For 40 years 99% of my coding has been in a language where you just write:
>
> A.len
>
> instead of:
>
> sizeof(A)/size(A[0])

But I suspect that language can pass the array to a function, and
that function also do A.len, right?

Even when we have a macro or language extension that calculates
sizeof(A)/sizeof(*A), it is only usable for arrays that were not passed
by pointer.

--
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.

Bart <bc@freeuk.cm> writes:
> On 04/01/2024 19:55, Janis Papanagnou wrote:
>> On 04.01.2024 19:35, Bart wrote:
>>>
>>> Now look at the basketcase that is C's attempt. C could EASILY have had
>>> an equivalent op that works like 'size'of'; it chose not to.
>> You're asking for an, say, 'nof_elements(A)', where there's
>> currently
>> only a 'sizeof(A)/sizeof(A[0])' existing? - Is that the whole resume
>> of this overly bulky subthread?
>
> Yes exactly.
>
> If you're arguing that it is such a trivial matter that it is hardly
> worth discussing, I can equally say that if it is that trivial, why
> isn't it just built-in? How hard can it be?

Implementing a new "lengthof" macro in an existing implementation?
Nearly trivial. (I picked the name for vague consistency with sizeof
and alignof.)

Implementing it in such a way that it can't easily be misused on an
argument of pointer type? A little harder, but I think solutions exist,
and it only has to be written once.

Implementing it as an operator, similar to sizeof and alignof?
Feasible, probably not a whole lot of work for each compiler. All
compilers implement sizeof, so all the information needed to implement
lengthof is already available -- and applying it to something that's a
pointer rather than array could be a constraint violation.

Standardizing it? Getting agreement on a name that (a) makes its
meaning clear and (b) doesn't conflict with existing code? (Or getting
agreement that breaking *some* existing code is acceptable?) Ensuring
that the specification covers all corner cases? Documenting it with
accuracy and precision comparable to other existing wording in the
standard? Reviewing that documentation and replying to complaints, some
valid, some not? Getting it into the next edition of the C standard and
getting all conforming implementations to provide it? Possible, but not
at all easy.

Demonstrating that there's enough demand to justify all this effort?
Explaining why the existing situation (individual programs either
defining their own macros or writing the expression inline and going to
some effort to ensure that such code, like all the other code, is
correct) is not good enough? Demonstrating that the current situation
actually causes serious problems? Not easy at all.

Any C implementation can provide such a macro as an extension. An
implementation could, for example, define a macro lengthof() in
<stddef.h>. I haven't checked, but I don't believe it does so, most
likely because few if any users have asked for it.

Nobody is claiming that C is a perfect language. If it had provided,
starting in C89, a built-in lengthof similar to sizeof, that would have
been fine and dandy. But the lack of such an operator has not been a
big enough problem to justify the *substantial* effort a universal
solution would require. There are a whole lot of nice-to-have features
that aren't in the language simply because they weren't part of the
language to begin with.

Sure, two software projects could use different names, and there could
be problems when merging code from them. Such problems can always occur
anyway, for a number of reasons. And such problems are solvable.

Note that most array objects are dealt with via pointers. Once you pass
an array to a function, the function sees it as a pointer, and *cannot*
determine how many elements it has. The feature you want could only be
used for an array object that's defined at block scope (local to a
function) or at file scope (outside any function).

[snip]

--
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 Thu, 4 Jan 2024 22:48:17 +0000, Bart wrote:

> For 40 years 99% of my coding has been in a language where you just
> write:
>
> A.len

Better still:

len(A)

which is just a generic wrapper around

A.__len__()

so it will work with your custom object types as well, all they have to do
is define a method with that name.

On 04/01/2024 23:14, Kaz Kylheku wrote:
> On 2024-01-04, Bart <bc@freeuk.cm> wrote:
>> On 04/01/2024 22:07, Jim Jackson wrote:

>>> I admire the preserverance
>>
>> For 40 years 99% of my coding has been in a language where you just write:
>>
>> A.len
>>
>> instead of:
>>
>> sizeof(A)/size(A[0])
>
> But I suspect that language can pass the array to a function, and
> that function also do A.len, right?

That depends. If the length is part of the type like in these 3
examples, then yes:

proc F1([5]int A) = println A.len end # by 'value'

proc F2(ref[5]int P) = println P.len end # by pointer**

proc F3([5]int &A) = println A.len end # by reference

(** It auto-derefs.) But it can only be called with an array of that
exact size:

[5]int A
[7]int B

F1(A)
F2(&A)
F3(A)

I can use A, but not B.

However most arrays passed to functions are unbounded (use [] not [N]),
since it is most useful to allow arrays of arbitrary length (this was
the problem with the first Pascals) then you will need a separate length
parameter.

Attempting A.len when A has type []int will give 0.

Alternately, slices can be used which carry their length:

proc F4(slice[]int S) = println S.len end

Now I can call it with both A and B, and without needing a separate length:

F4(A)
F4(B)

Or with a slice of an array:

F4(B[3..5]) # displays 3, but the bounds are 1..3

> Even when we have a macro or language extension that calculates
> sizeof(A)/sizeof(*A), it is only usable for arrays that were not passed
> by pointer.

The test lengthof(A) implementation which I did in 20 minutes the other
day, doesn't report an error when A is not an array; it just ignores it
and does sizeof(). So it will take bit longer to make it robust.

On 04/01/2024 23:25, Lawrence D'Oliveiro wrote:
> On Thu, 4 Jan 2024 22:48:17 +0000, Bart wrote:
>
>> For 40 years 99% of my coding has been in a language where you just
>> write:
>>
>> A.len
>
> Better still:
>
> len(A)
>
> which is just a generic wrapper around
>
> A.__len__()
>
> so it will work with your custom object types as well, all they have to do
> is define a method with that name.

If a language has a built-in like A.len or len(A) or A'len and so on,
then it can choose to allow overloading for that operator. The syntax
chosen doesn't matter.

It doesn't need to take a heavy-handed approach like C++ or Python.

On Fri, 5 Jan 2024 01:53:00 +0000, Bart wrote:

> If a language has a built-in like A.len or len(A) or A'len and so on,
> then it can choose to allow overloading for that operator. The syntax
> chosen doesn't matter.

The operation still has to be defined for the relevant type, in order for
the construct to work.

> It doesn't need to take a heavy-handed approach like C++ or Python.

Given that the entire Python language definition is a small fraction of
that of, say, Java, which does not allow operator overloading on user-
defined types, I would hardly describe it as “heavy-handed”.

On 04.01.2024 21:17, Bart wrote:
> On 04/01/2024 19:55, Janis Papanagnou wrote:
>> On 04.01.2024 19:35, Bart wrote:
>>>
>>> Now look at the basketcase that is C's attempt. C could EASILY have had
>>> an equivalent op that works like 'size'of'; it chose not to.
>>
>> You're asking for an, say, 'nof_elements(A)', where there's currently
>> only a 'sizeof(A)/sizeof(A[0])' existing? - Is that the whole resume
>> of this overly bulky subthread?
>
> Yes exactly.

Fine.

>
> If you're arguing that it is such a trivial matter that it is hardly
> worth discussing, I can equally say that if it is that trivial, why
> isn't it just built-in? How hard can it be?

Why so paranoid defensive? :-) I wasn't arguing (not yet), I was asking
two questions; one was what appears to be the essence of thousands lines
of posts with a lot repetitions. (And the other was on the posting meta
level, with the implicit hope to come to an end since everything seems
to have been said on that theme.) Also the two questions you have added
here (seemingly as virtual counter-argument) had already been addressed.

>
> The subthread was actually about the macro system, and this example was
> one I gave where macros make it possible for every man and his dog to
> create their own sloppy, incompatible workaround.

I'm sure I already read arguments on that many times in this thread. My
view is that all the programming areas create (also sloppy) workarounds
for features that are not part of the "language of choice" (here: "C").

Specifically when discussing C there's IMO countless examples of what's
missing, and what's wrongly designed, and whatnot. - Thus I am merely
astonished that you fastened on that bit so vigorously, and also with
so much text and repetitions.

>
> Every other app seems to provide their own version; I gave three where
> so far we have ArraySize, SDL_arraysize, and ARRAY_SIZE.
>
> You yourself have suggested 'nof_elements'. You see the problem?

Not the least. The sizeof/sizeof I consider as an idiomatic approach
to achieve for a special detail of the language a practical solution.

And the naming of entities in programs through identifiers will always
be individual, while in practice typically with semantically sensible
naming. I really don't care if programmers call her entities X or Y.
Only if a language designer (or committee) decides to add a feature as
a standard part of the language it becomes important.

There's (IMO) so much wrong with arrays in C that the discussed special
case (which is also not generally applicable as pointed out repeatedly)
is of little interest (for me; YMMV).

>
> I'm not actually too bothered about that (I know C is never going to
> have anything that is that sensible), I'm arguing against attitudes like
> yours that it doesn't matter.

Yet - despite dozens of posts with thousands of lines - I haven't seen
any convincing argument that it would matter.

>
> My original point may have been this: suppose C's macro system didn't
> exist. Would that have given enough impetus to whoever was or were
> responsible for the language, to actually do it properly?

That's a noteworthy statement since formulated as thought experiment.
But the hypothetical precondition shows that it's really not worth a
discussion in the first place.

Mind, I started with K&R C in the 1980's, at a time where much more
sophisticated languages had already been present; the formally much
more appealing Algol(68), the concepts-outstanding Simula(67), even
Pascal (that you recently also mentioned) was very appealing due to
its simplicity, efficiency, expressiveness and still clearness, just
to name a few. What I was missing in C - one major issue was the OO
capabilities that I had got used with Simula - I later found in C++,
alongside with the efficiency of C inherited, but also with all the
deficiencies of C; but for some features you've got alternatives
(e.g. sophisticated STL containers replacing these (IMO annoying)
low-level "C arrays" (with all its inhomogeneities), and providing
yet much more that I appreciated).

>
> Since my conjecture was that C's macro scheme stopped it evolving normally.

Above we identified a "resume" of the previous posts. Another one
shall finalize this post; no one is forced to use C. - Myself I'm
using it occasionally where appropriate. But if I think something
is in my way - and may it be only as unimportant as 'A.length' -
I'll just switch to another language (with richer feature set, or
with a more coherent design). It certainly wouldn't occur to me to
ask for features that I already find in many contemporary language
I can choose from.

I'm confident your mileage may vary, and we can agree to disagree.
:-)

Janis

On 05/01/2024 02:53, Bart wrote:
> On 04/01/2024 23:25, Lawrence D'Oliveiro wrote:
>> On Thu, 4 Jan 2024 22:48:17 +0000, Bart wrote:
>>
>>> For 40 years 99% of my coding has been in a language where you just
>>> write:
>>>
>>>       A.len
>>
>> Better still:
>>
>>      len(A)
>>
>> which is just a generic wrapper around
>>
>>      A.__len__()
>>
>> so it will work with your custom object types as well, all they have
>> to do
>> is define a method with that name.
>
> If a language has a built-in like A.len or len(A) or A'len and so on,
> then it can choose to allow overloading for that operator. The syntax
> chosen doesn't matter.
>
> It doesn't need to take a heavy-handed approach like C++ or Python.
>

One option for a useful array length operator/function/macro is a simple
and limited feature that works for arrays of known size and gives a hard
(compile-time) error when the size is not known. The one you have in
your own language covers most of that, except for the insanity of
evaluating to 0 when given a pointer/reference to an "unbounded" array.
The "ARRAY_SIZE" macro in Linux is almost perfect - the only
disadvantage is that it relies on compiler extensions:

#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))

#define __same_type(a, b) __builtin_types_compatible_p(typeof(a),
typeof(b)))

#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))

#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))

The other option is a general mechanism for "length" as an
operator/function/macro that can be applied to a wide range of types -
including user-made types, assuming the language supports user-defined
types. Whether that is done by function overloads, custom methods,
etc., is a design choice.

Bart <bc@freeuk.cm> writes:
>On 04/01/2024 23:25, Lawrence D'Oliveiro wrote:
>> On Thu, 4 Jan 2024 22:48:17 +0000, Bart wrote:
>>
>>> For 40 years 99% of my coding has been in a language where you just
>>> write:
>>>
>>> A.len
>>
>> Better still:
>>
>> len(A)
>>
>> which is just a generic wrapper around
>>
>> A.__len__()
>>
>> so it will work with your custom object types as well, all they have to do
>> is define a method with that name.
>
>If a language has a built-in

The C language doesn't have such a built-in. Any discussion that
assumes it does, or will, is pointless.

David Brown <david.brown@hesbynett.no> writes:
[...]
> One option for a useful array length operator/function/macro is a
> simple and limited feature that works for arrays of known size and
> gives a hard (compile-time) error when the size is not known. The one
> you have in your own language covers most of that, except for the
> insanity of evaluating to 0 when given a pointer/reference to an
> "unbounded" array. The "ARRAY_SIZE" macro in Linux is almost perfect -
> the only disadvantage is that it relies on compiler extensions:
>
> #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
> __must_be_array(arr))
>
> #define __same_type(a, b) __builtin_types_compatible_p(typeof(a),
> typeof(b)))
>
> #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
>
> #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
[...]

When you wrote "in Linux", I wondered if you were being imprecise, but
in fact that code is in the Linux kernel.

That means the macros aren't directly available to normal C code, but
you can always copy their definitions (*if* you're using a compiler
that supports the __builtin_types_compatible_p extension).

--
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 05/01/2024 15:54, Scott Lurndal wrote:
> Bart <bc@freeuk.cm> writes:
>> On 04/01/2024 23:25, Lawrence D'Oliveiro wrote:
>>> On Thu, 4 Jan 2024 22:48:17 +0000, Bart wrote:
>>>
>>>> For 40 years 99% of my coding has been in a language where you just
>>>> write:
>>>>
>>>> A.len
>>>
>>> Better still:
>>>
>>> len(A)
>>>
>>> which is just a generic wrapper around
>>>
>>> A.__len__()
>>>
>>> so it will work with your custom object types as well, all they have to do
>>> is define a method with that name.
>>
>> If a language has a built-in
>
> The C language doesn't have such a built-in. Any discussion that
> assumes it does, or will, is pointless.

It could be an extension.

I assume none of your code uses extensions to standard C? Not even
inline assembly?