Re: size_t best practice

Liste des GroupesRevenir à l c 
Sujet : Re: size_t best practice
De : tr.17687 (at) *nospam* z991.linuxsc.com (Tim Rentsch)
Groupes : comp.lang.c
Date : 18. Aug 2024, 13:32:40
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <86plq6dq1z.fsf@linuxsc.com>
References : 1
User-Agent : Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Mark Summerfield <mark@qtrac.eu> writes:

[what type to use for array indexing?]

I've also noticed that quite a few array-related algorithms
_assume_ that indexes are signed, so again I have to put in
guards to avoid subtracting below zero when I use size_t when
implementing them.
>
So is it considered best practice to use int, long, long long,
or size_t, in situations like these?

There is no single "best practice".  Some people are firmly of
the opinion that signed types should be used everywhere.  Other
people are firmly of the opinion that unsigned types should be
used for variables whose domain can never be negative, such as
counts and array indices.  There is no single answer that will
get agreement from everyone.

Having said that, I have two recommendations.

One, for the particular case of array indices, use a typedef
to define a type name to be used exclusively for the purpose
of indexing arrays.  My own practice is to use 'Index' for
this type, but what name is used is less important than that
there be one (following local naming conventions, etc).

Two, write code so that any use of such types will work whether
the underlying types are signed or unsigned.  In other words
don't rely on either signed semantics or on unsigned semantics
for uses of those variables.  Following this precept may need
more mental effort than using a type of known signedness, but
it provides a collateral benefit in that it's easier, in many
cases, to verify the correctness of the code written.  That
benefit makes it worth the effort.


Date Sujet#  Auteur
18 Aug 24 * size_t best practice23Mark Summerfield
18 Aug 24 +* Re: size_t best practice3Ike Naar
18 Aug 24 i`* Re: size_t best practice2Mark Summerfield
20 Aug 24 i `- Re: size_t best practice1Andrey Tarasevich
18 Aug 24 +- Re: size_t best practice1Michael S
18 Aug 24 +- Re: size_t best practice1Tim Rentsch
18 Aug 24 +* Re: size_t best practice6Stefan Ram
18 Aug 24 i+* Re: size_t best practice4Michael S
19 Aug 24 ii`* Re: size_t best practice3Tim Rentsch
19 Aug 24 ii `* Re: size_t best practice2Michael S
19 Aug 24 ii  `- Re: size_t best practice1Tim Rentsch
18 Aug 24 i`- Re: size_t best practice1Tim Rentsch
20 Aug 24 +* Re: size_t best practice7Andrey Tarasevich
20 Aug 24 i+* Re: size_t best practice3Andrey Tarasevich
20 Aug 24 ii`* Re: size_t best practice2Andrey Tarasevich
22 Aug 24 ii `- Re: size_t best practice1Tim Rentsch
22 Aug 24 i`* Re: size_t best practice3Tim Rentsch
22 Aug 24 i `* Re: size_t best practice2Ike Naar
22 Aug 24 i  `- Re: size_t best practice1Tim Rentsch
24 Aug 24 +* Re: size_t best practice3Bonita Montero
25 Aug 24 i`* Re: size_t best practice2Bonita Montero
26 Aug 24 i `- Re: size_t best practice1Vir Campestris
27 Aug 24 `- Re: size_t best practice1Bonita Montero

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal