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

Groups > comp.lang.c > #387642

Re: size_t best practice

Show key headers only | View raw

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.

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.

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