Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #390195

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

Show all headers | View raw

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

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Results of survey re. a new array size operator Alexis <flexibeast@gmail.com> - 2025-01-24 17:57 +1100
  Re: Results of survey re. a new array size operator Michael S <already5chosen@yahoo.com> - 2025-01-24 13:56 +0200
    Re: Results of survey re. a new array size operator scott@slp53.sl.home (Scott Lurndal) - 2025-01-24 14:16 +0000
      Re: Results of survey re. a new array size operator Kaz Kylheku <643-408-1753@kylheku.com> - 2025-01-24 20:10 +0000
        Re: Results of survey re. a new array size operator scott@slp53.sl.home (Scott Lurndal) - 2025-01-24 22:12 +0000
          Re: Results of survey re. a new array size operator Kaz Kylheku <643-408-1753@kylheku.com> - 2025-01-25 00:57 +0000
            Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-29 01:48 -0800
              Re: Results of survey re. a new array size operator bart <bc@freeuk.com> - 2025-01-29 11:45 +0000
                Re: Results of survey re. a new array size operator Michael S <already5chosen@yahoo.com> - 2025-01-29 14:24 +0200
                Re: Results of survey re. a new array size operator Richard Damon <richard@damon-family.org> - 2025-01-29 07:24 -0500
                Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-29 08:01 -0800
                Re: Results of survey re. a new array size operator James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-01-29 11:09 -0500
                Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-29 08:18 -0800
  Re: Results of survey re. a new array size operator James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-01-24 08:56 -0500
    Re: Results of survey re. a new array size operator Kaz Kylheku <643-408-1753@kylheku.com> - 2025-01-24 20:24 +0000
      Re: Results of survey re. a new array size operator James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-01-24 20:32 -0500
        Re: Results of survey re. a new array size operator Kaz Kylheku <643-408-1753@kylheku.com> - 2025-01-25 02:40 +0000
          Re: Results of survey re. a new array size operator James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-01-25 00:06 -0500
      Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-29 02:13 -0800
    Re: Results of survey re. a new array size operator antispam@fricas.org (Waldek Hebisch) - 2025-01-24 23:13 +0000
      Re: Results of survey re. a new array size operator Kaz Kylheku <643-408-1753@kylheku.com> - 2025-01-25 01:17 +0000
      Re: Results of survey re. a new array size operator James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-01-24 20:57 -0500
        Re: Results of survey re. a new array size operator antispam@fricas.org (Waldek Hebisch) - 2025-01-25 21:18 +0000
          Re: Results of survey re. a new array size operator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-25 16:28 -0800
            Re: Results of survey re. a new array size operator antispam@fricas.org (Waldek Hebisch) - 2025-01-26 01:48 +0000
            Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-29 02:31 -0800
  Re: Results of survey re. a new array size operator Kaz Kylheku <643-408-1753@kylheku.com> - 2025-01-24 19:45 +0000
    Re: Results of survey re. a new array size operator Alexis <flexibeast@gmail.com> - 2025-01-25 09:39 +1100
      Re: Results of survey re. a new array size operator Kaz Kylheku <643-408-1753@kylheku.com> - 2025-01-25 01:16 +0000
    Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-29 02:17 -0800
  Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-29 02:19 -0800
  Re: Results of survey re. a new array size operator Ben Bacarisse <ben@bsb.me.uk> - 2025-01-29 16:00 +0000
    Re: Results of survey re. a new array size operator David Brown <david.brown@hesbynett.no> - 2025-01-29 18:01 +0100
      Re: Results of survey re. a new array size operator Ben Bacarisse <ben@bsb.me.uk> - 2025-01-30 00:31 +0000
        Re: Results of survey re. a new array size operator David Brown <david.brown@hesbynett.no> - 2025-01-30 10:59 +0100
        Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-30 12:13 -0800
          Re: Results of survey re. a new array size operator scott@slp53.sl.home (Scott Lurndal) - 2025-01-30 21:33 +0000
            Re: Results of survey re. a new array size operator Kaz Kylheku <643-408-1753@kylheku.com> - 2025-01-30 22:31 +0000
            Re: Results of survey re. a new array size operator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-02-18 19:46 -0800

csiph-web