Summary of responses - Conversion to C++

Thank you everyone for your responses. Some of you wanted the responses
to be summarized. So here it is....


The consensus is that no matter how much people may dislike COBOL, there
is a large installed base of COBOL and many of them may wish to convert to
C++. The reasons may range from political ones to maintaining
compatibility of older systems with newer applications designed and built
with C++. (This has to do with not having too many people in the
organization with different expertise in different areas).


1. Real C++ programming requires a change in the way programs are designed
      and coded. In fact, a lot of people use the C++ compiler but write code
      that is similar to C.


      If the conversion is being done to exploit the inherent properties of the
      language, it is a REVERSE ENGINEERING effort which would involve going
      through the existing code, working backwards their current design,
      redesigning it the object oriented way and then re-coding. This will be
      a manual effort.


  2. Installations who want to convert for ease of maintenance of old
        applications (because most of their new applications and staff are
        working on C++) may be satisfied with an automated converter which
        cannot really redesign their application.


          I got a lead to check out Boston Technical Distribution Corp. at
          (617) 248-8989 and ask them for information on their XperCASE tool.
          The XperCASE tool is a tool built by SIEMENS AG, Germany and it has
          supposedly the ability to re-engineer COBOL code into structure
          diagrams.
          From the structure diagram, you can apparently develop C++ code. I have
          not yet had the time to check this out.


3. Many respondents pointed out that even with a converter and assuming
        straight conversion, there may be many aspects of COBOL which might
        create problems like
          a) ALTER statement to change flow of control
          b) requirement of additional C++ libraries to support decimal (money)
                classes and picture clause editing that will be rampant in a
                commercial application.
          c) Readability: nicely structured COBOL may give very readable C++ (?).
                But if there are GOTO's to paragraphs in other sections, the
                resultant converted code may be heavily mangled.
          d) Handling Redefinitions of memory areas, string manipulations and
                record handling capabilities which is the forte of COBOL
          e) In-line SORT verb which may be invoked within the program


4. Loss of efficiency is something we might have to expect in any converted
        software (especially if automated).


5. As one person pointed out the number of people who know and love both
        COBOL and C++ is close to zero and both languages are too clever (in
        different ways) to let anyone else do it!
--

Return to the comp.compilers page.
Search the comp.compilers archives again.