Re: Top 10 most common hard skills listed on resumes...

On 09/09/2024 01:29, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

No.  It is essential for efficiency to have 32-bit types.  On 32-bit
machines doing otherwise would add useless instructions to object
code.  More precisly, really stupid compiler will generate useless
intructions even with my declarations, really smart one will
notice that variables fit in 32-bits and optimize accordingly.
But at least some gcc versions needed such declarations.  Note
also that my version makes clear that there there is
symmetry (everything should be added using 64-bit precision),
you depend on promotion rules which creates visual asymetry
are requires reasoning to realize that meaning is symetric.

Your posted code used 64-bit aritmetic. The xext and c 32-bit variables were used in loops where they need to be widened to 64 bits anyway. The new value of c is set from a 32-bit result.
(Have you tried 64-bit versions of xext, yext, c to see it it makes any difference? I may try it myself if I can set up a suitable test, but I can only test on a 64-bit machine.
Do you still have 32-bit machines around? I haven't been able to find one for a decade and a half!)

In my version type of pp is clearly visible, together with casts
this gives string hint what is happening: this is 32-bit addition
producing carry in 'c'.

It seems to do a 64-bit addition with a carry on bit 32 of the result stored in c.

Note, I did not intend to post a trap for you, but in your
egerness to shorten the code you removed important information.
And while this code is unlikely to change much (basically
upgrade to 64-bit version on 64-bit machines in the only likely
change), normally code evolves and your version is harder
to change.

3 copies of 'pp' is a bit harder to change than one!
Your code is basically doing 'p = a[i] + b[i] + c' in a loop, but spread over multiple lines and completed buried in all those 'unsigned long long' declarations:
         unsigned long long pp = (unsigned long long)(xp[i])
                               + (unsigned long long)(yp[i])
                               + (unsigned long long)c;
That was my main objection. And yes, all those casts because of mixing 32/64-bit arithmetic is another source of clutter.

More generally, my aim is to make code obviously correct
(I not saying that I was fully successful in this case).
I consider your version worse, because with your version
reader has more work checking correctness (even taking into
account that you lowered number of lines).

Sorry, I think mine (either version I posted) is easier to check.

Anyway, I illustrated to you how I use declarations in the middle
of a function.  There is nothing chaotic about this, type is
declared when variable first time gets its value.  And in most
cases variable scope is tiny.  AFAICS neither early Pascal nor
your language allows me to write programs in this way.

You can write declarations mixed within code in my language, but they will have function-wide scope. I tend to do that only for temporary code.

And if
you do not see benefits, well, this your loss.

Average number of local variables in a half-dozen C codebases I surveyed was 3 variables per function. So I find it hard to see the point of splitting them up into different scopes!