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

Groups > comp.lang.c > #390360

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

Show all headers | View raw

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben@bsb.me.uk> writes:
>>
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 29/01/2025 17:00, Ben Bacarisse wrote:
>>>>
>>>>> Alexis <flexibeast@gmail.com> writes:
>>>>>
>>>>>> JeanHeyd Meneide, a Project Editor for WG14, has just posted the
>>>>>> results of a survey re.  the preferred form of a new array size
>>>>>> operator:
>>>>>>
>>>>>> -- https://thephd.dev/the-big-array-size-survey-for-c-results
>>>>>
>>>>> Curious.  The top objection to the usual macro solution is given
>>>>> as:
>>>>>    * double-evaluation of e.g. getting the size of the 1-d part of
>>>>>      a 2-d array
>>>>>      int meow[3][4]; /* ... */ SIZE_KEYWORD(meow[first_idx()]);
>>>>> Does the author not know that there is no evaluation of the
>>>>> operands of sizeof in this example?
>>>>
>>>> 6.5.3.4p2 :
>>>>
>>>> """
>>>> If the type of the operand is a variable length array type, the
>>>> operand is evaluated;  otherwise, the operand is not evaluated and
>>>> the result is an integer constant.
>>>> """
>>>>
>>>> I don't know if that is the source of the double-evaluation concern
>>>> here, but it is certainly a situation in which sizeof /does/
>>>> evaluate its operand.
>>>
>>> It would have been a good idea to pick an example that behaves as
>>> claimed.  Let's hope this sort of casual approach is reserved for
>>> blogs.
>>
>> All of the motivational examples listed are lame.  Everyone knows
>> that macro calls might evaluate an argument twice, and so to avoid
>> calling macros on expressions with side-effects.  It's true that
>> the usual macro definition to determine array extent misbehaves
>> but that can simply be called out as a warning without needing to
>> codify the situation by putting it in the C standard;  in other
>> words it's a quality of implementation issue, not a language issue
>> (and some cases are already diagnosed by both gcc and clang).  As
>> for the problem of name collision, choosing a longer name and
>> having it be all caps (as most macro names should be) gives a
>> collision cross section that is vanishingly small.  Either of the
>> names ARRAY_INDEX_LIMIT() or ARRAY_EXTENT() are both descriptive
>> enough and unlikely-to-collide enough that they can be used
>> without any significant danger of collision.
>>
>> What would be better is to give some general tools that would
>> allow a user-defined macro to be written safely.  For example:
>>
>>   _Has_array_type( e )       1 if and only if the expression
>>                              'e' has array type
>>
>>   _Is_side_effect_free( e )  1 if and only if the expression
>>                              'e' has no side effects, so
>>                              multiple evaluations have no
>>                              negative consequences
>>
>> Furthermore because these tests are likely to be called only
>> inside macro definitions, using the _Leading_capital style of
>> naming shouldn't be a problem.
>
> Seems like a lot of cruft just to save a small bit of
> typing by the programmer.
>
> The decades old standard idiom of sizeof(x)/sizeof(x[0])
> is self-documenting and requires no macros or new language
> features.

Speaking for myself personally, I don't mind using the common
idiom (although I consider it better practice to write a macro
for it, but that is a minor point), and consider the proposal
to add a new language construct to the C standard to be worse
than simply a waste of time.

The point of my earlier comment is that, if something is going to
be added to the C standard, it would be better if what were added
provided some generality so it could be used for more than just
the number of elements in an array.  An endless series of special
cases is anathema to good language design.

Back to comp.lang.c | Previous | Next — Previous 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