home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12470 < prev    next >
Encoding:
Text File  |  1992-08-17  |  2.1 KB  |  57 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!microsoft!hexnut!jimad
  3. From: jimad@microsoft.com (Jim Adcock)
  4. Subject: Re: Language extension
  5. Message-ID: <1992Aug18.004603.17116@microsoft.com>
  6. Date: 18 Aug 92 00:46:03 GMT
  7. Organization: Microsoft Corporation
  8. References: <memo.575428@cix.compulink.co.uk>
  9. Lines: 46
  10.  
  11. In article <memo.575428@cix.compulink.co.uk> vadim@cix.compulink.co.uk writes:
  12. | #for f in  #methods(T) 
  13. |  #if f == T::T  && #visibility(f) == public
  14. |   Constrained(#arglist(f)) : T(#params()) { check(); }
  15. |  #endif
  16. | #endfor
  17. |};
  18. |
  19. |Actually the TI  C++ Preprocessor has somewhat similar capabilities,
  20. |but it is limited by fact that it is a PREPROCESSOR, and does not
  21. |have full access to all compiler data structures.
  22. |
  23. |What do you think?
  24.  
  25. Some ideas:
  26.  
  27. * C++ currently has *two* "preprocessors" -- one is the historical
  28. #ifdef #endif #gunk from "C" prehistory, the other is the "preprocessing"
  29. implied by templates.  We should head away from the "C" #gunk and move
  30. towards better "template" capabilities instead.  Current template proposal
  31. is simply much too weak.
  32.  
  33. * Given better preprocessing, you still have to be able to use the "built-in"
  34. syntax of the language to perform your "enhanced" functionality, or people
  35. simply won't use it.  For example:
  36.  
  37.     GCed_pointer<foo> pfoo = new Foo;
  38.  
  39. is not acceptable to "real world" programmers.  It must be possible to have the
  40. "GC'ed"-ness associate with Foo [actually, with a base class of Foo] and
  41. then allow classes to override the built-in behavior of ALL the aspects of
  42. that class, including pointers and references, such that the end programmer
  43. just writes:
  44.  
  45.     Foo* pfoo = new Foo;
  46.  
  47. and pfoo is automatically a GC'ed pointer.
  48.  
  49. * IF you can accomplish these tasks -- namely seamlessly add functionality
  50. to the language, then the next problem that you find is that C++ code 
  51. optimizers are not up to the task.  This problem in turn is to a large extent
  52. due to problems of uncontrolled and undefined aliasing in C++, which prevents
  53. code generaters for coming up with reasonable code -- especially in the case
  54. of "simple" objects such as smart pointers.
  55.  
  56.  
  57.