Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #387634
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: size_t best practice |
| Date | 2024-08-18 04:32 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <86plq6dq1z.fsf@linuxsc.com> (permalink) |
| References | <VdCcne2MOeshN1z7nZ2dnZfqnPWdnZ2d@brightview.co.uk> |
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.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar
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