home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11592 < prev    next >
Encoding:
Text File  |  1992-07-26  |  2.8 KB  |  63 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mole-end!mat
  3. From: mat@uunet.uu.net!mole-end
  4. Subject: Re: Renew?
  5. Message-ID: <1992Jul27.072223.11801@uunet.uu.net!mole-end>
  6. Summary: Proposals to x3j16/WG21
  7. Organization: :
  8. References: <1992Jul5.002414.390@frumious.uucp> <1992Jul25.151227.8156@hemlock.cray.com>
  9. Date: Mon, 27 Jul 1992 07:22:23 GMT
  10. Lines: 51
  11.  
  12. In article <1992Jul25.151227.8156@hemlock.cray.com>, de@cray.com (Duane Eitzen) writes:
  13.  
  14. > On the topic of submitting a proposal: how does one do this? How
  15. > much time should one expect to spend doing it? What percentage of
  16. > external proposals are successful?
  17.  
  18. Several of the big C++/OO magazines published an article last year by
  19. Bjarne Stroustrup on just this topic.  The spirit was `Please don't, but
  20. if you insist on doing it, here's what you must do to have a ghost of a
  21. chance.'
  22.  
  23. There's a lot of work involved, including analysis of how the proposal
  24. would interact with other stuff.  C++ is sufficiently rich (like Ben&Jerry's
  25. ice cream!) that this is a non-trivial task and should be undertaken by
  26. several people, preferably with experience in compilers and language
  27. semantics.  (Actually, more like a `whole calamari' flavor of B&J's, if
  28. you get my drift.)
  29.  
  30. What percentage are `successful'?  If you mean `what percentage are
  31. accepted more or less in the form in which they were submitted?' maybe
  32. one in twelve.  If you mean `What percentage influence the language?'
  33. the number might be a little higher.  (Of course, the season isn't over
  34. yet, so the percentages aren't complete.)
  35.  
  36. Proposals by people who've worked in the guts of C++ are more likely to
  37. address the issues squarely, and probably have a much better chance than
  38. a proposal written by J. Random User.  (I've seen some simple ones that
  39. I thought worthy, but that never saw the light of day.)  Proposals made
  40. by representatives of large user groups (e.g. an SQL standards body)
  41. have a better chance of commanding attention, but not necessarily a
  42. better chance of acceptance.
  43.  
  44. My opinion on this one is that it is a non-starter.  You CAN'T just go
  45. moving stuff around in C++; it really is tied to the Object model of
  46. programming and the referential attributes that represent relationships
  47. have to be maintained (i.e. you can't tolerate dangling pointers).  To
  48. make this work, you have to think through not only C++ and its semantics,
  49. but the nature of OO programming and how OO maps into C++.  It's job
  50. somewhere between Huge and Fu'Cryin'OutLoud Huge.  You are trying to
  51. shoehorn a brontosaurus into a Habitrail(tm, probably) and it just won't
  52. go.
  53.  
  54. realloc() as it stands in C is nice because you MAY be able to expand
  55. an array in place.  But C++ tends to work free store harder, and it's
  56. less likely, given N. Random Storage Manager, that you'll reap the
  57. benefit.
  58. -- 
  59.  (This man's opinions are his own.)
  60.  From mole-end                Mark Terribile
  61.  
  62.  uunet!mole-end!mat, Somewhere in Matawan, NJ
  63.