Path: ...!weretis.net!feeder8.news.weretis.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: rbowman <bowman@montana.com>
Newsgroups: comp.os.linux.misc,comp.os.linux.advocacy
Subject: Re: GIMP 3.0.0-RC1
Date: 12 Feb 2025 20:47:38 GMT
Lines: 43
Message-ID: <m14fnaFflhnU3@mid.individual.net>
References: <vkjmdg$30kff$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>
	<slrnvqq09r.38buj.candycanearter07@candydeb.host.invalid>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net ywX+Cj7DPiLKS9NxBn1upQWH/sV9w/aW7yby2+krc/KpVGQggN
Cancel-Lock: sha1:HQ0rv50ipwXlg74PPL0KOvPp6Vo= sha256:JODm8EHbhaWnq1W3gMewORI6SHNk4Z1U+S0KtPu946o=
User-Agent: Pan/0.160 (Toresk; )
Bytes: 3751

On Wed, 12 Feb 2025 20:20:04 -0000 (UTC), candycanearter07 wrote:

> 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?

Yes. It was coated with syntactic sugar in C++ but it's often convenient 
to malloc/calloc an array and pass around the pointer. If you run out of 
room you can then realloc. 

There are several ways to shoot yourself in the foot if you're 
inexperienced. A common problem is not realizing the void* pointer 
returned by realloc may (usually) not be the same as the original pointer 
so if you're hanging onto references of where the data used to be you'll 
probably segfault (sooner or later).

Like John said newer languages try to protect you from yourself but there 
is no magic. Either the programmer is keeping track efficiently or the 
language is adding extra code to do the job.