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

Groups > comp.lang.c > #387649

Re: size_t best practice

Show all headers | View raw

On Sun, 18 Aug 2024 15:23:58 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> Michael S <already5chosen@yahoo.com> writes:
> 
> > On 18 Aug 2024 12:17:36 GMT
> > ram@zedat.fu-berlin.de (Stefan Ram) wrote:
> >  
> >> Mark Summerfield <mark@qtrac.eu> wrote or quoted:
> >>  
> >>> So is it considered best practice to use int, long, long long, or
> >>> size_t, in situations like these?  
> >>
> >>   In *cough*C++*cough* you could whip up a "SafeSize" class with
> >>   a bulletproof "operator--", so you don't space on the check.
> >>   You could still keep cranking out your code in what's basically C
> >> and just cherry-pick this one gnarly feature from that other
> >> language.
> >>
> >> SafeSize& operator--()
> >> { if( value == 0 )
> >>   { throw std::underflow_error("SafeSize decrement underflow"); }
> >>   --value;
> >>   return *this; }  
> >
> > But that's not a desired behavior for people that want to write
> > downcounting for() loops in intuitive manner.  
> 
> Kind of a funny use of the word intuitive, for two reasons.
> 
> The first is that writing for() loops, especially C for() loops,
> is learned behavior.  There can be patterns that one is used to,
> but they are not "intuitive" in the usual sense of the word.
> 
> The second is that people who program in C are accustomed to the
> idea of an asymmetry between counting up and counting down,
> because of how pointers work.  It's okay to increment a pointer
> to one past the end of an array;  it is not okay to decrement a
> pointer to one before the beginning of an array.  Because of that
> the patterns for going forward and for going backward are just
> different.  It seems odd to use the word "intuitive" to recognize
> that distinction.
>

I would think that very large part of 'C' programmers ignores this
asymmetry. They are helped by the fact that 100% of production 'C'
compilers ignore it as well, which means that in practice code that
compares &arr[0] with &arr[-1] works as naively expected on all targets
that have flat memory model and far more often than not works on more
tricky targets as well.

> Which is not to say I disagree with what you are saying.  Actually
> I guess I'd have to say I'm not sure what it is you are saying.
> To my way of thinking the function above doesn't change the way I
> would write down-counting loops.  It might be useful as a debugging
> aid aide, but nothing more (and an assert() is probably better).
> I think though that what you're saying is something else but I'm
> not sure what it is.

Nothing fancy. Just an ability to write downcounting loops in a
way that I, obviously mistakenly, consider intuitive.
for (i = len-1; i >= 0; --i)

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

Thread

size_t best practice Mark Summerfield <mark@qtrac.eu> - 2024-08-18 08:03 +0000
  Re: size_t best practice Ike Naar <ike@sdf.org> - 2024-08-18 08:38 +0000
    Re: size_t best practice Mark Summerfield <mark@qtrac.eu> - 2024-08-18 10:15 +0000
      Re: size_t best practice Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-08-20 07:38 -0700
  Re: size_t best practice Michael S <already5chosen@yahoo.com> - 2024-08-18 12:36 +0300
  Re: size_t best practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-18 04:32 -0700
  Re: size_t best practice Michael S <already5chosen@yahoo.com> - 2024-08-18 15:40 +0300
    Re: size_t best practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-18 15:23 -0700
      Re: size_t best practice Michael S <already5chosen@yahoo.com> - 2024-08-19 11:13 +0300
        Re: size_t best practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-19 09:43 -0700
  Re: size_t best practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-18 14:57 -0700
  Re: size_t best practice Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-08-20 06:53 -0700
    Re: size_t best practice Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-08-20 06:55 -0700
      Re: size_t best practice Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-08-20 06:56 -0700
        Re: size_t best practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-22 01:38 -0700
    Re: size_t best practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-22 01:31 -0700
      Re: size_t best practice Ike Naar <ike@sdf.org> - 2024-08-22 11:19 +0000
        Re: size_t best practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-22 06:12 -0700
  Re: size_t best practice Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-24 19:49 +0200
    Re: size_t best practice Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2024-08-25 06:30 +0200
      Re: size_t best practice Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-25 06:53 +0200
        Re: size_t best practice Vir Campestris <vir.campestris@invalid.invalid> - 2024-08-26 21:39 +0100
  Re: size_t best practice Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-27 18:11 +0200

csiph-web