Re: size_t best practice

Path	csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From	Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups	comp.lang.c
Subject	Re: size_t best practice
Date	Sun, 18 Aug 2024 14:57:23 -0700
Organization	A noiseless patient Spider
Lines	21
Message-ID	<86ed6lebp8.fsf@linuxsc.com> (permalink)
References	<VdCcne2MOeshN1z7nZ2dnZfqnPWdnZ2d@brightview.co.uk> <operator-20240818131412@ram.dialup.fu-berlin.de>
MIME-Version	1.0
Content-Type	text/plain; charset=us-ascii
Injection-Date	Sun, 18 Aug 2024 23:57:23 +0200 (CEST)
Injection-Info	dont-email.me; posting-host="c515e38b156ea485062cf8517e8b6236"; logging-data="2668448"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19tscoQSX2mfpL2Jy2f25hGXmZ2ol7tHzA="
User-Agent	Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock	sha1:jyiUwIMzVIx/xffbv7Q2cyl+hac= sha1:BKUs/fy0R5CFeoI4dWz7dI/ADa8=
Xref	csiph.com comp.lang.c:387640

Show key headers only | View raw

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> 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; }

Besides this facility not being a solution to the underlying
problem, C++ has diverged from C to the point where it is
no longer possible to program in C++ as "basically C".

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