home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / applicat / 9558 < prev    next >
Encoding:
Text File  |  1992-12-21  |  2.8 KB  |  67 lines
  1. Newsgroups: comp.sys.amiga.applications
  2. Path: sparky!uunet!mcsun!ub4b!sunbim!usenet
  3. From: accs1@bagheera.mumath
  4. Subject: Re: Is SAS C V6 C++ compatible
  5. Message-ID: <1992Dec21.095036.27419@sunbim.be>
  6. Sender: usenet@sunbim.be (user news)
  7. Reply-To: accs1@bagheera.mumath
  8. Organization: Sun Microsystems
  9. References: <BzGIpJ.HGy@unx.sas.com>
  10. Date: Mon, 21 Dec 92 09:50:36 GMT
  11. Lines: 54
  12.  
  13. In article HGy@unx.sas.com, walker@twix.unx.sas.com (Doug Walker) writes:
  14. >
  15. >In article <1992Dec17.090233.26443@sunbim.be>, accs1@bagheera.mumath writes:
  16. >|> I wonder it will require SAS/C 6.x. Does this mean it will produce C-source
  17. >|> code which is to be compiled with 6.x ? When I talked to the guys from SAS 
  18. >|> during the 'AMIGA Messe' in Cologne in 1991 they said it will *for sure* directly
  19. >|> produce object code.
  20. >
  21. >I'm sorry, but you are wrong.  I was one of the guys there and we
  22. >were saying no such thing, because it is not true.
  23. >
  24. >I have a hard time understanding why people are SO CONCERNED that
  25. >the C++ not use C as an intermediate step.  You will never see the
  26. >C file produced unless you ask to; the process will be as seamless
  27. >as using the C compiler itself.  Speed and debuggability are not
  28. >dependent on the intermediate language used.  Choice of algorithms
  29. >in the translator is more important than the fact that it uses
  30. >C as an intermediate.
  31. >
  32. >Eventually the translator will be modified and will replace the C
  33. >front-end completely, but not in the first version.  Keep in mind
  34. >that some intermediate language will always be used, that's the
  35. >way that compilers work. 
  36. >
  37. >|> Frank
  38. >
  39. >-- 
  40. >  *****
  41. >=*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =
  42. > *|. o.| ||                                          1200/2400/9600 Dual
  43. >  | o  |//     For all you do, this bug's for you!
  44. >  ====== 
  45. >usenet: walker@unx.sas.com                            bix: djwalker 
  46. >Any opinions expressed are mine, not those of SAS Institute, Inc.
  47. >
  48.  
  49.  
  50.  
  51. Its just fine with me that the compiler produces some intermediate language (whichever
  52. it is) and its even more fine if I don't see unless I want to see it. I was concerned
  53. that I would get C source _only_ as the compile result and need to run a separate
  54. C-compiler to get my executable. I'm sorry that I made you understand it wrong.
  55.  
  56. So, the guys from the fair where right. It will produce executable code. I start the
  57. C++ compiler and after a while, and I'm sure that while could be made shorter when
  58. getting rid of the C front-end, I will get my executable. Lattice C++ did the same.
  59.  
  60. Have you ever considered turn-around times as being important? Not that I would change
  61. to a PC, but seeing the compile speed of Turbo-Pascal or Turbo-C simply impresses me.
  62.  
  63. Will the debugger, which is hopefully delivered with the compile package, handle it
  64. properly (meaning: I'm debugging my C++ source and not the C source) ? 
  65.  
  66. Frank  
  67.