home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16342 < prev    next >
Encoding:
Text File  |  1992-11-11  |  2.5 KB  |  56 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!destroyer!gatech!hubcap!mjs
  3. From: mjs@hubcap.clemson.edu (M. J. Saltzman)
  4. Subject: Re: Fortran to C conversion: Why bother?
  5. Message-ID: <1992Nov11.185431.13154@hubcap.clemson.edu>
  6. Organization: Clemson University, Clemson SC
  7. References: <1992Nov9.131601.167@gems.vcu.edu> <20849@fritz.filenet.com> <1992Nov11.172747.1959@mksol.dseg.ti.com>
  8. Date: Wed, 11 Nov 1992 18:54:31 GMT
  9. Lines: 45
  10.  
  11. In article <1992Nov11.172747.1959@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
  12. >In <20849@fritz.filenet.com> scotth@felix.filenet.com (Scott Hopson) writes:
  13. >
  14. >>In article <1992Nov9.131601.167@gems.vcu.edu> hleaves@gems.vcu.edu writes:
  15. >>>I was wondering why anyone would bother using the f2c (or similar) program to
  16. >>>translate fortran code directly into C. 
  17. >>>[...]
  18.  
  19. >>[...]
  20. >>Many companies think seriously about converting their old code into new code,
  21. >>even if the functionality is the same. This is because they usually want the
  22. >>same functionality but with the opportunity to enhance old systems.
  23. >
  24. >The problem with this decision is that the code resulting from
  25. >automatic translations is usually something less than maintainable, so
  26. >you would still have to either maintain the FORTRAN or reimplement in
  27. >maintainable C.  
  28.  
  29. That's right, but maintaining the Fortran isn't such a bad way to go.
  30. One of the points in this thread is that "f2c | cc" is a perfectly
  31. servicable Fortran compiler substitute for many applications.
  32.  
  33. >Converters are useful for those cases where you need
  34. >to get the first release of a product out the door when you are in a
  35. >new environment, but IMHO trying to maintain the output of a converter
  36. >after chucking the original code is rather like maintaining object
  37. >after chucking the source code.  It is somewhat more difficult than taking
  38. >the time to reimplement properly in the new language.
  39.  
  40. I don't think it's widely a widely-advocated strategy to maintain the
  41. *output* of any program generator.  You always maintain the input.
  42. It's more or less like compiling your C code, throwing away the source
  43. and trying to maintain the code using the assembler listing.
  44.  
  45. >
  46. >-- 
  47. >"Insisting on perfect safety is for people who don't have the balls to live
  48. > in the real world."   -- Mary Shafer, NASA Ames Dryden
  49. >------------------------------------------------------------------------------
  50. >Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
  51.  
  52. -- 
  53.         Matthew Saltzman
  54.         Clemson University Math Sciences
  55.         mjs@clemson.edu
  56.