Deutsch   English   Français   Italiano  
<slrnvqq09r.38buj.candycanearter07@candydeb.host.invalid>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
Newsgroups: comp.os.linux.misc,comp.os.linux.advocacy
Subject: Re: GIMP 3.0.0-RC1
Date: Wed, 12 Feb 2025 20:20:04 -0000 (UTC)
Organization: the-candyden-of-code
Lines: 26
Message-ID: <slrnvqq09r.38buj.candycanearter07@candydeb.host.invalid>
References: <vkjmdg$30kff$1@dont-email.me> <vl8qm7$3u6t2$1@dont-email.me>
 <vl93dl$3vkun$1@dont-email.me> <vl9449$3vo6h$3@dont-email.me>
 <vl9aov$pp7$1@dont-email.me> <vla4hr$5n4v$1@dont-email.me>
 <vlblqj$harb$1@dont-email.me> <lttopaFoh2cU8@mid.individual.net>
 <vle8uk$12sii$2@dont-email.me>
 <c686fb74-4fac-0809-7005-417c76ee0e3b@example.net>
 <nbReP.633803$oR74.271654@fx16.iad> <NnVeP.44028$vfee.11890@fx45.iad>
 <vo6ubb$3ue2q$2@dont-email.me>
 <RhOdnY5Kb8vulDr6nZ2dnZfqnPudnZ2d@earthlink.com>
 <vo7lp6$25uo$2@dont-email.me>
 <655acbf6-05e5-69ff-8a44-9f7075aafa2e@example.net>
 <ddNpP.567620$iNI.244105@fx14.iad> <m0pqs3ForauU2@mid.individual.net>
 <g9qcnUmy1pxdrTX6nZ2dnZfqnPqdnZ2d@earthlink.com>
 <m0r59mFrbnU1@mid.individual.net> <yn0qP.587031$iNI.359829@fx14.iad>
 <VtWdnaJY5fz99zT6nZ2dnZfqnPudnZ2d@earthlink.com>
 <20250210093054.00001375@gmail.com> <vofgo6$1p8fn$1@dont-email.me>
 <KwSdnd_yRPwhvjH6nZ2dnZfqnPidnZ2d@earthlink.com>
 <20250212081704.00003ce1@gmail.com>
Injection-Date: Wed, 12 Feb 2025 21:20:04 +0100 (CET)
Injection-Info: dont-email.me; posting-host="f80a7ae3e8f39be66f2aed63157aeaa8";
	logging-data="2621056"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/pPcs0AnrzFwILidlVUBATj7T884isQoDodwPF61j8BA=="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:SOaqjC+wKDX8A0vh6O1UEyDvJ8M=
X-Face: b{dPmN&%4|lEo,wUO\"KLEOu5N_br(N2Yuc5/qcR5i>9-!^e\.Tw9?/m0}/~:UOM:Zf]%
 b+ V4R8q|QiU/R8\|G\WpC`-s?=)\fbtNc&=/a3a)r7xbRI]Vl)r<%PTriJ3pGpl_/B6!8pe\btzx
 `~R! r3.0#lHRE+^Gro0[cjsban'vZ#j7,?I/tHk{s=TFJ:H?~=]`O*~3ZX`qik`b:.gVIc-[$t/e
 ZrQsWJ >|l^I_[pbsIqwoz.WGA]<D
Bytes: 3447

John Ames <commodorejohn@gmail.com> wrote at 16:17 this Wednesday (GMT):
> On Tue, 11 Feb 2025 23:29:43 -0500
> "WokieSux282@ud0s4.net" <WokieSux283@ud0s4.net> wrote:
>
>> Nothing wrong, or unique, about fixed-size arrays. You don't want
>> them for some stuff, do want them for other stuff. CAN elim a lot of
>> range-checking code.
>
> Nothing wrong with fixed-size arrays as a general concept, no. Treating
> the size as *part of the type specification* so that passing ARRAY
> [1..15] OF CHAR to a function expecting ARRAY [1..10] OF CHAR yields a
> type mismatch is what's utterly demented; a true Wirth original, that.
>
> I have never yet heard a sensible case made for a language where array
> sizes are known, but no FOR EACH IN (x) construct is provided. Doing it
> C's way at least offers you flexibility and performance in exchange for
> the risk of shooting yourself in the foot; offering a way to iterate
> transparently across arrays of arbitrary size at least gives you safety
> and convenience in exchange for the performance penalty of bounds-
> checking. Wirth's approach offers the worst of both worlds, for no
> material gain whatsoever - absolutely bonkers.


If you really need to, you can also pass by pointer?
-- 
user <candycane> is generated from /dev/urandom