Re: Results of survey re. a new array size operator

bart <bc@freeuk.com> writes:

On 29/01/2025 09:48, Tim Rentsch wrote:
>

Kaz Kylheku <643-408-1753@kylheku.com> writes:
>

On 2025-01-24, Scott Lurndal <scott@slp53.sl.home> wrote:
>

Kaz Kylheku <643-408-1753@kylheku.com> writes:
>

On 2025-01-24, Scott Lurndal <scott@slp53.sl.home> wrote:
You can define
>
  #define arraysize (x) (sizeof (x) / sizeof ((x)[0))

>
You can, but you don't need to.

>
The repetition in things like:
>
   sizeof foo->bar.buf / *sizeof foo->bar.buf
>
is just irksome.  Why do I have to say that thing twice,
to get its number of elements?
>

Often readability suffers
when you use macros, not to mention the other quirks of
C macro use (in C++, a constexpr function might be
suitable, but the naming being arbitrary (e.g. arraysize,
NUM_ELEMENTS, SIZE, et alia) doesn't aid in readability
or maintainability.

>
The naming being arbitrary is the argument for standardizing the
name for the macro and sticking it into, for instance, <stddef.h>.
>
If we didn't have offsetof there, we might have to deal with
OFFSETOF, offsetof, offset, member_offset, and others.

>
That's a flawed analogy.  A macro to compute the number of
elements in an array can be done in standard C.  The
functionality of offsetof cannot be done in standard C, and
that's what it needs to be in the standard library.

>
Can't it?  The various versions I've seen, including mine, look
like this:
>
  #define offsetof(a,b) (size_t) &( ((a*)0) -> b)

That form of expression is not guaranteed to work, as other
responses have explained.

As for the other point that was made, when looking at open source
code, every other program seems to contain macros like
>
  MAX
  ARRAYLEN
  STREQ
>
But with assorted spellings (the first program I looked at today used
MZ_MAX).
>
However, every other program also seems to use typedefs to define
their own versions of INT32 etc, even with stdint.h type being
available for 25 years.

Probably historical baggage.  It was ten years after C89 that C99
added <stdint.h>, and probably five more years before people
started using C99 regularly.  And it didn't help that Microsoft,
in their near-infinite wisdom, didn't ever really support C99,
and waited until C11 before doing an implementation conforming to
a current C standard.  So the pre-C99 names had many years to
become entrenched, and after that there was no sufficiently
motivating reason to change them.  If it ain't broke don't fix
it.

So being in the standard is not enough if the official name is
too ugly or it is fiddly to type.

Personally I think the type names added in <stdint.h> are both
ugly and almost always a bad choice for other reasons.  That
said, I note that uint32_t and uint64_t have become nearly
ubiquitous (and also uint8_t, which is completely baffling, since
unsigned char can be used instead, along with some form of static
assertion for people who are overly obsessive).