Did you ever look beyond the C-code at the assembly, figure out why the pointers you manipulate
were not allowed in Fortran, and not even in a pure C++ program??
Why not just write
hubbadubby = malloc(5Byte)
abbadubby=hubbadubby + 4 ; (pointers, whatever way you define it)
wait for all memory to get defragmennted, moved around, and try to access abbaduddy - 2, instead
of hubbadaddy + 3?? (ouch, plus minus one, or something similar)
Compared to Fortran "descriptors" of Hubbadaddy[5] and Addabubby[3-5}, ouch,
that already told you not to do it.
(Fortran descriptors defined starting point and lenght, and the programmer only the where to access, C++
supports that too, but not only that)
Much like
Hubbydaddy.abbaduddy.get(oldguy-4), giving some chance for the compiler to catch whatever you
are trying to do, and even for the operating system to move it all to another place in memory, to keep the footprint
defragmented.
More important, and in general, there is little need for the hupper-level programmer to know at what absolute adress
his hubbadaddies are, just like in Fortran and Basic, who knows where the operating system moves them when
every now and then packing up the memory??
Anyway, huppyduppy that MSFT has introduced both fortran descriptors and basic string handling,
but not yet really handling the memory holes, the taks fo the operating system.
Ilmarinen
The magic of crash-and-bloath to mishandle java is another story, much more on the destructive side.
I still remember the 3 days it took me to rewrite one of my old C program to make in totally indifferent to any
stupid mallocs I had made.
Assembly is obviously in another universe, they should never meet, except through a decent operating system.
That is
- compiler catccing the worst bugs (in debug and not-debug mode)
- operating system able to move around, defragment memory, and the stuff still works
after that, add the capabilty to do some real-time stuff, predicatabilty and priorities |
