home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / oracle / 2605 < prev    next >
Encoding:
Text File  |  1992-12-22  |  2.6 KB  |  64 lines
  1. Newsgroups: comp.databases.oracle
  2. Path: sparky!uunet!mcsun!chsun!osnbe!
  3. From: rheiger@renext.eiger.olivetti.ch (Richard H. E. Eiger)
  4. Subject: Re: Pro*C
  5. Message-ID: <1992Dec20.105229.955@osnbe.Olivetti.ch>
  6. Sender: @osnbe.Olivetti.ch
  7. Nntp-Posting-Host: renext
  8. Reply-To: rheiger@renext.eiger.olivetti.ch
  9. Organization: Olivetti (Schweiz) AG, Branch Office Berne
  10. References: <1992Dec17.220804.12585@tigger.jvnc.net>
  11. Date: Sun, 20 Dec 1992 10:52:29 GMT
  12. Lines: 50
  13.  
  14. In article <1992Dec17.220804.12585@tigger.jvnc.net> fogelinc@nmr1.Cyanamid.COM  
  15. (Carl Fogelin) writes:
  16. > In article 13161@den.mmc.com, richard@crowded-house.den.mmc.com (Richard  
  17. Armstrong) writes:
  18. > >
  19. > >I have plenty of good things to say about Oracle Pro*C. However, let me
  20. > >focus on one area where I find Pro*C completely brain-dead.
  21. > >
  22. > [stuff deleted]
  23. > >
  24. > >Why doesn't the Pro*C precompiler do #define substitutions?
  25. > 
  26. > Because the scope of the Pro*C preprocessor would probably get out of hand.
  27. > Sure, it would be nice if the Pro*C preprocessor would at least recognize 
  28. > #defines which are at the top of the current module, but the c preprocessor
  29. > can be much more complicated.  What about #defines found in an #include file?
  30. > What about #defines which use conditional assignments (i.e., #ifdef)?  These
  31. > are just a couple of complications, but if you think about it, I'm sure you
  32. > can come up with more.
  33. > 
  34. > Yes, I agree that I wish Pro*C did the #define substitutions, but I  
  35. understand
  36. > why they didn't do it.  What I don't understand is why "struct"ures are not
  37. > valid for host variables, but VARCHARs (which are structures) are...  8-(
  38. > 
  39. > -------------------------------------
  40. > Carl Fogelin (fogelinc@cyanamid.com) 
  41. > 
  42.  
  43. The problems described here are a nuisance, I agree. But there are things I  
  44. find much much worse in PRO*C. For instance, you can specify ireclen and  
  45. oreclen. But, PRO*C still has an upper limit. When that is reached your output  
  46. will be erratic without warning!
  47.  
  48. The other real stupidity is that PRO*C is not clever enough to put "#line nnn  
  49. file.pc" statements into the output. It would be so much less of a pain to find  
  50. errors in the .pc source when the C-compiler complains. And also runtime output  
  51. from the assert macro would finally be useful.
  52.  
  53. The solution to this is to preprocess the .pc file before feeding it to pcc.
  54.  
  55.     Just my 2 cents.
  56.     Richard
  57. --
  58.                          
  59.     ___           _____2
  60.    /   )  /  /   /        Richard H. E. Eiger
  61.   /_ _/  /__/   /__       Ing. Informatik HTL
  62.  /\     /  /   /          Unregistered NeXT fan
  63. /  \   /  /   /_____      rheiger@renext.eiger.olivetti.ch (NeXT mail welcome)
  64.