Path: ...!feeds.phibee-telecom.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Michael S Newsgroups: comp.lang.c Subject: Re: size_t best practice Date: Mon, 19 Aug 2024 11:13:03 +0300 Organization: A noiseless patient Spider Lines: 66 Message-ID: <20240819111303.00004a7a@yahoo.com> References: <20240818154013.00002ed7@yahoo.com> <86a5h9eagx.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Date: Mon, 19 Aug 2024 10:12:26 +0200 (CEST) Injection-Info: dont-email.me; posting-host="63e4d7165886f0c08d939b274e907ed0"; logging-data="2440532"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19HChAw1uZCMBXQF+nrjdVPZk48UbGjJYo=" Cancel-Lock: sha1:WNr/f5WR5mOEL0ajod/EnvnpYCE= X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32) Bytes: 3870 On Sun, 18 Aug 2024 15:23:58 -0700 Tim Rentsch wrote: > Michael S writes: > > > On 18 Aug 2024 12:17:36 GMT > > ram@zedat.fu-berlin.de (Stefan Ram) wrote: > > > >> Mark Summerfield 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. > I would think that very large part of 'C' programmers ignores this asymmetry. They are helped by the fact that 100% of production 'C' compilers ignore it as well, which means that in practice code that compares &arr[0] with &arr[-1] works as naively expected on all targets that have flat memory model and far more often than not works on more tricky targets as well. > 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. Nothing fancy. Just an ability to write downcounting loops in a way that I, obviously mistakenly, consider intuitive. for (i = len-1; i >= 0; --i)