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

Groups > comp.lang.c > #390189

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

Show all headers | View raw

On 1/29/25 6:45 AM, bart wrote:
> 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)

Which has undefined behavior, the deferencing of a null pointer.

Only if the implementation defines that behavior to be what we want, can 
that be done.  Most implementtions, that sort of behavior turns out to 
work out, but it isn't mandated by the Standard.

> 
> 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.
> 
> So being in the standard is not enough if the official name is too ugly 
> or it is fiddly to type.
> 

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

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