Re: GIMP 3.0.0-RC1

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.