home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / c / 12585 < prev    next >
Encoding:
Text File  |  1992-08-20  |  3.2 KB  |  100 lines
  1. Path: sparky!uunet!uunet.ca!geac!censor!isgtec!robert
  2. From: robert@isgtec.com (Robert Osborne)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Macros for ANSI prototypes
  5. Message-ID: <3160@isgtec.isgtec.com>
  6. Date: 20 Aug 92 15:04:10 GMT
  7. References: <1992Aug18.170108.1827@druid.uucp>
  8. Sender: news@isgtec.com
  9. Lines: 89
  10.  
  11. darcy@druid.uucp (D'Arcy J.M. Cain) writes:
  12. #robert@isgtec.com (Robert Osborne) writes:
  13. #>darcy@druid.uucp (D'Arcy J.M. Cain) writes:
  14. #>> [...] The K&R code just becomes one of the stages of the
  15. #>> compilation. [...]
  16. #>>     ANSI C --> K&R C --> Assembler --> a.out
  17. #>> You see the K&R is simply an intermediate stage and is thrown out after
  18. #>> along with the .s and .o files.
  19. #>Gaak!  This is gross.
  20. #>You can't throw away the K&R step because you need the source for
  21. #>debuggers.
  22. #
  23. #Who said you had to throw it away immediately?  In fact the example I use
  24. #later involved copying the K&R code to another box and compiling there.  By
  25. #"after" I meant "after it is no longer needed."  I kind of thought that was
  26. #obvious.
  27.  
  28. Well since the K&R code is always needed while the .s and .o are not
  29. this wasn't that 'obvious'.
  30.  
  31. #>The K&R systems are used also for development; there are enough
  32. #>problems with the compilers and with the speed of compile without
  33. #>adding yet another preprocessing step.
  34. #>
  35. #>It would only take one major bug introduced by the ANSI to K&R
  36. #>step to remove the developer time savings.
  37. #
  38. #If your tools don't work then get ones that do.  I mean if we are going
  39. #to discuss the use of various tools we have to assume that cpp does macro
  40. #processing by the accepted rules, cc compiles C code and all the other
  41. #tools perform as advertised.  I don't think it matters where a major bug
  42. #is introduced.  If a tool is broken it will cost the developer time.
  43. #Just ask anyone who does development using compilers from you-know-who
  44. #with a version number of x.0.
  45.  
  46. Get a grip.  I was just saying the cost of the added complexity of a
  47. extra preprocessing step has to be weighed against the cost of not
  48. using it.   If the minor difficulties caused by cpp were not grossly 
  49. overwhelmed by being able to conditionally compile and #include files
  50. would you use it?  If the development ease/speed gains from using C
  51. didn't overwhelm the power of assembler would you use C?
  52.  
  53. #>I do not consider this even remotely as elegant as the prototype macros.
  54. #
  55. #My way:
  56. #
  57. #int foo(char *, int);
  58. #...
  59. #int foo(char *bar, int n)
  60. #{
  61. #  /* stuff */
  62. #}
  63. #
  64. #Your way: (I don't have the original message but I think this is close)
  65. #
  66. #int foo(__DECL((char *, int));
  67. #...
  68. #int foo __DEFN((char *bar __ int n))
  69. #{
  70. #  /* stuff */
  71. #}
  72.  
  73. I agree the original method, not mine, suggested was very (VERY!) ugly.
  74. I don't use the ANSI style for function arguments so...
  75. My way:
  76.  
  77.     --- in some include ---
  78.     #ifdef HAS_PROTOTYPES
  79.     #define PROTO(s) s
  80.     #else
  81.     #define PROTO(s) ()
  82.     #endif
  83.     
  84.     --- in junk.c ---
  85.     int foo PROTO((char *, int));
  86.  
  87.     int foo(bar, n)
  88.     char *bar;
  89.     int n;
  90.     {
  91.     }
  92.     
  93. Since prototypes are generated by a tool (mkptypes in our case)
  94. this is easier and more elegant (in my mind and that in those of
  95. the rest of our group) than either of the above methods.
  96.  
  97. Rob.
  98. --
  99. Robert A. Osborne   ...!uunet.ca!isgtec!robert or robert@isgtec.com
  100.