How to solve the same numerical Problem in 7 different Programming Languages

168
  • Re: “Break standard conforming code is a good thing”, note Fortran 202X breaks conforming code and it was ok with the committee, why is that?

There are at least two apps in production use with a team I have worked with in industry who have conformant and functioning Fortran library code which will break on account of the change brought about by the standard committee with Fortran 202X. The following trivial reproducer gets to the underlying issue:

   integer, parameter :: LENS = 10
   character(len=:), allocatable :: s
   s = repeat( ' ', ncopies=LENS )
   write( s, "(g0)" ) "x"
   print *, "len(s) = ", len(s)
   print *, len(s) == LENS
end

The behavior of the program per current standard is

 len(s) =  10
 T

With a Fortran 202X conformant compiler, the behavior will change to

 len(s) =  1
 F

The above apps rely on the string length not changing due to subsequent internal I/O once they are allocated to certain desired length in another part (initialization) of the library.

I brought my concerns due to this change and its implications to the committee members several times, even during the committee meeting. But to no avail. Perhaps it is because the above two apps are not of interest to the holy “they” of the @mecej4 fame, so breaking these apps is entirely ok? This is why keep asking “For whom Fortran, for what?”

  • Re: “Your response was expected.” - a needless and useless comment again, veering again toward ad hominem.

I do NOT espouse breaking change generally. However implicit mapping and implied save are 2 aspects where the benefits to Fortran from doing away with them far exceed the status quo. With implicit mapping, it will be over 50 years of recognition - imagine that, 50 years! - that its use can lead to unsafe code. Few languages out there hold on to a bad feature like that.

1 Like