home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / cplus / 18838 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  3.3 KB
  1. Xref: sparky comp.lang.c++:18838 comp.object:4737
  2. Newsgroups: comp.lang.c++,comp.object
  3. Path: sparky!uunet!wupost!spool.mu.edu!news.cs.indiana.edu!noose.ecn.purdue.edu!author.ecn.purdue.edu!roger
  4. From: roger@author.ecn.purdue.edu (Roger J Cass)
  5. Subject: Re: Pros and cons of C++
  6. Message-ID: <roger.726503589@author.ecn.purdue.edu>
  7. Sender: news@noose.ecn.purdue.edu (USENET news)
  8. Organization: Purdue University Engineering Computer Network
  9. References: <C0Hp1n.vp@gpu.utcs.utoronto.ca>
  10. Date:  8 Jan 93 14:33:09 GMT
  11. Lines: 51
  12.  
  13. I am an engineer (well, actually still a grad student), so my approach to
  14. using a language is maybe a little different.  I was involved in a finite-
  15. element mesh generation package development group as part of my graduate work.
  16. We chose C++ for a number of reasons. based on the technology as it stood
  17. about 2 years ago.
  18.  
  19. First, like some of the other articles have stated, C++ offered the widest
  20. platform of hardware.  At Sandia Nat'l Labs, where my research was sponsored,
  21. the software had to be able to run on a number of high performance
  22. workstations.  We were engineers turned programmers, not the other way.  We
  23. knew exactly what the software had to do, because we were inventing the
  24. solution as we went.  We had to pick some sort of standard that would allow
  25. us to concentrate on getting better at mesh generation rather that worrying
  26. about having to write the entire package.
  27.  
  28. In our search for modules that could take care of as much of our program as
  29. possible, we discovered that OO technology was really the best *idea*, if
  30. we could just find an existing solution.
  31.  
  32. We chose C++ because we needed a solid modeller that we could build on, that
  33. would become a module in our program, not the program itself.  The ACIS
  34. modeller by Spatial Technologies was the deciding factor.  We also needed
  35. a GUI, and X seemed the best alternative since it was built in to all the
  36. workstations.  Here again, the match between C++ and C was the clincher.
  37.  
  38. In the course of our program development, I ran into limitations in C++ very
  39. quickly, but most were able to be worked around.  If our original concept
  40. was purely OO, then our final product (which is available as part of DOE
  41. technology transfer, contact me via email) is a network of patches to
  42. make it a program.  The original OO framework has been lashed together
  43. and short-circuited.  I am the first to admit that if I had been a better
  44. C++ programmer, it wouldn't have been so bad, but overall I think we did
  45. the best we could.
  46.  
  47. SUMMARY-- In my observations at 2 universities (BYU and Purdue) and at a
  48. National Laboratory (Sandia) not very
  49. many engineers have embraced the OO paradigm for modelling physical
  50. systems and solving engineering analyses.  C++ is a good way to move into
  51. OOP, but does not allow the OO paradigm to be realized in full-- which is
  52. important to an engineer/programmer who does not care to become a guru just
  53. to solve a problem.  Many engineers of still using **hack** FORTRA(SH)
  54. (sorry, can't help it), and wouldn't care too much which OO language to
  55. move into, except that it must be widely available.
  56.  
  57. I am still waiting for the successor to C++ as the OO programming language
  58. of choice so I can get on with OO problem solving instead of programming.
  59. --
  60. Roger Cass               ! No success can compensate
  61. roger@ecn.purdue.edu     ! For failure in the home
  62. Purdue University CADLAB ! David O. Mackay
  63. (317)494-5944            !
  64.