Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #387682
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: size_t best practice |
| Date | 2024-08-22 01:31 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <86ed6h9cxm.fsf@linuxsc.com> (permalink) |
| References | <VdCcne2MOeshN1z7nZ2dnZfqnPWdnZ2d@brightview.co.uk> <va275j$3d6tp$1@dont-email.me> |
Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> On 08/18/24 1:03 AM, Mark Summerfield wrote:
>
>> However, this means I have to be very careful never to decrement a
>> size_t of value 0, since, e.g., size_t size = 0; size--; results in
>> size == 18446744073709551615.
>
> That's a completely incorrect conclusion. There's nothing wrong
> with decrementing a 0 of type `size_t`. It results in perfectly
> defined behavior. It produces a `(size_t) -1` value.
>
> For example, iteration all the way to 0 can be idiomatically
> implemented as
>
> for (some_unsigned_type i = size; (some_unsigned_type) i != -1; --i)
> ...
>
> This will work, even though it will eventually decrement a zero
> value. If you are sure that the type is "large" (e.g. `int` or
> larger), then the cast is unnecessary
>
> for (some_unsigned_type i = size; i != -1; --i)
> ...
>
> (Note, BTW, that it also works perfectly for signed index types.)
>
>
>> So I need to guard against this. Here is an example I'm using
>> (without the assert()s):
>>
>> void vec_insert(vec* v, size_t index, void* value) {
>> if (v->_size == v->_cap) {
>> vec_grow(v);
>> }
>> for (size_t i = v->_size - 1; i >= index; --i) {
>> v->_values[i + 1] = v->_values[i];
>> if (!i) // if i == 0, --i will wrap!
>> break;
>> }
>> v->_values[index] = value;
>> v->_size++;
>> }
>
> No, that's rather weird and unnecessarily overwrought way to guard
> against this.
>
> We can immediately apply the pattern I demonstrated above to this
> and get
>
> for (size_t i = v->_size - 1; i != index - 1; --i)
> v->_values[i + 1] = v->_values[i];
>
> Done. No need for an extra safeguard.
Better (please ignore cosmetic layout differences):
for( size_t i = v->_size; i > index; i-- ){
v->_values[i] = v->_values[i-1];
}
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