One way to address these kinds of memory management problems would be if the standard allowed MOVE_ALLOC() to shallow copy between pointer arrays and allocatable arrays. If this were allowed, then the programmer could use C_LOC() and C_F_POINTER() to get the data located in the right place, and then use MOVE_ALLOC() to to shallow copy that pointer array to an allocatable array (with full benefits of the allocatable attributes afterwards).
As for aliasing objects beyond the f77 data types (e.g. int8, int16, int128, real16, real128, etc.), the fortran standard has been very reluctant to define this, even going back to f90 when the opportunity first arose. I assume that they donāt want to address the issues related to padding bits and memory address restrictions (e.g. a real64 entity with an odd memory address). It does seem like they could go a little further than they have, however. For example, they could at least define the behavior of transfer() between entities with the same storage_size() such as int64/real64/logical64, int128/real18/logical128, and so on. That, combined with allowing mvbits() to operate on integers of different kinds and adding the kind argument to ibits() would solve many of my practical problems.
A possible way : overallocating the tables so you donāt have to resize them at all. On modern OSās, allocated memory remains virtual until it is first-touched, so if you have say 32 GB RAM you can allocate as many tables of 30 GB as you want, and itās only when you start defining the elements that the physical memory gets used. Of course thereās no magic, and the total amount of data you can define cannot excess the RAM+SWAP amount (unless using memory mapped files, but this wonāt be efficient).
This can work only if the types of the tables do not have components that are initialized (in this cas the entire table is first-touched at the allocation).
It has been disappointing to watch how ideology has been attacking such useful FORTRAN statements as EQUIVALENCE and GOTO for so long.
I donāt see much evidence to this āscienceā of what is unsafe coding practice.
We should appreciate Kahanās contribution to the better understanding of round-off, as without this ideology would have destroyed that as well. How many users of Fortran know what numerical precision they should be selecting ?
Come onā¦ Havenāt you seen some legacy spaghetti codes with wild GOTOās and no indentation, making them extremely difficult to understand and maintain? The problem is not GOTO in itself, it is how GOTOās are used. Itās possible to write clean and structure codes with GOTOās, but itās also very easy to mess up everything.
By the way, GOTO is still there. Itās just that the language has now many control structures that make GOTO mostly useless and that are more self-explanatory than GOTO.
EQUIVALENCE is a bit different issue, as thereās no safer feature that can replace it.
Wellā¦ EQUIVALENCE seems to still be useful under certain (corner) cases. But GOTO is kind of awful.
And the standards committee didnāt even bother to mark GOTO as obsolescent (so thatās safe for now); Fortran 2008 simply added the ability to exit from any named construct, thus rendering it implicitly obsolete.
I remember having whole conventions around GOTO (e.g., going to 77 meant cleanup; going to 99 meant error). The problem is that those conventions were only in my head. They werenāt as explicit as, for example:
subroutine sub1(..., ERROR)
...
trying: block
...
if (failed) then
err = 'something went wrong'
exit trying
endif
...
return ! successful return
end block trying
if (present(ERROR)) ERROR = err
end subroutine
And in the same vein, I recall that, before NEWUNIT was introduced, I had the tendency to use unit numbers greater than 100, just to avoid unintended disconnections of pre-connected units ābut again, that convention was only in my head.
I am indeed wondering if there still exist corner cases where a GOTO could still be useful (i.e. with no better ways with other statements)? As a matter of fact, I canāt remember when was the last time I had to use it in new codes.
In C there is at least the case where one wants to exit from nested loops, as the exit statement can only exit from the inner loop. Then a goto is the simplest solution.
Explicitly, I donāt think so. But a few I/O-related options rely on labelsā¦ although, I donāt recall when was the last time I used the FORMAT statement instead of a format string.
In the next C standard, break and continue are acquiring labels, so that case may go away.
I think there is one case (and only one) were GO TO is useful and there is not a better way to handle that particular case. That case is where you want to immediately exit to the end of a routine to process an error prior to exit or termination of the program. You can use BLOCK/EXIT BLOCK but that means you are creating a separate āscoping unitā inside your routine and can get a little tricky deciding where you want the block to start and end.. Iām not sure what that does to optimization. For this case, GO TO would be a lot more acceptable if you could have alphanumeric as opposed to just numerical labels. ie GO TO error_handler instead of GOTO 12345
Since the ācompanion processorā (i.e., C/C++) has to deal with potentially nested scopes every time a {...} block is encountered, I think the pattern is well known (and any related performance penalty, negligible).
I believe I recall in some notes that unions (with a bind(c) requirement) are being added to the next standard revision. Obviously thatās years out from being in effect, but I believe many compilers already support unions in some form today. If a union fits your needs it might be a safer approach than equivalence.