home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12657 < prev    next >
Encoding:
Text File  |  1992-08-20  |  3.2 KB  |  70 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!centerline!matt
  3. From: matt@centerline.com (Matt Landau)
  4. Subject: Re: Return value for the constructors.
  5. Message-ID: <matt.714332315@centerline.com>
  6. Sender: news@centerline.com
  7. Nntp-Posting-Host: rapier
  8. Organization: CenterLine Software, Inc.
  9. References: <1992Aug19.163545.25066@sunb10.cs.uiuc.edu> <1992Aug19.175852.38459@watson.ibm.com> <1992Aug19.231926.28218@sunb10.cs.uiuc.edu> <2273@devnull.mpd.tandem.com> <matt.714318343@centerline.com> <1992Aug20.170524.3452@sunb10.cs.uiuc.edu>
  10. Distribution: usa
  11. Date: Thu, 20 Aug 1992 17:38:35 GMT
  12. Lines: 56
  13.  
  14. In <1992Aug20.170524.3452@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
  15. >In <matt.714318343@centerline.com> matt@centerline.com (Matt Landau) writes:
  16. >>In <2273@devnull.mpd.tandem.com> rgp@mpd.tandem.com (Ramon Pantin) writes:
  17. >>>>>Sure there is: Overload operator new()...
  18. >>>>
  19. >>>>*****>    Clever...but it's not reentrant.
  20.  
  21. >>>Paul, that is a moot point given that the object might not always be
  22. >>>created thru new ...
  23.  
  24. >>Of course it's fairly straightforward to FORCE all objects of a given
  25. >>class to be created via the class operator new ...
  26.  
  27. >*****>    And this is supposed to be clean and simple??  Anyway, not
  28. >    allowing auto objects to too high a price to pay.
  29.  
  30. No, I never said it was clean and simple, just that it was possible.  
  31.  
  32. In fact, I think it's a bad idea in most cases, although without a widely
  33. available implementation of exception handling, most of the alternatives 
  34. for handling constructor failure are also pretty gross.  
  35.  
  36. My own style has evolved to one in which I try very hard to write ctors 
  37. that CANNOT fail, and put failure-prone operatations into a secondary
  38. initialization member function that's called after construction.  (I'm well 
  39. aware that this technique also makes it difficult or impossible to write 
  40. certain kinds of classes; for those, we just use a different kludge :-)
  41.  
  42. This is ungraceful, and the kind of thing that ctors were supposed to 
  43. avoid in the first place by ensuring that an object will be initialized 
  44. before it can be used, but the pragmatics seem to be that without any
  45. exception handling, ctors fall short of the goal.  
  46.  
  47. >>Arrays are still a problem...
  48.  
  49. >>Presumably this limitation would go away if X3J16 actually designed an
  50. >>operator new[] and someone actually implemented it :-)
  51.  
  52. >*****>    Or better, when exception-handling gets here.
  53.  
  54. Yes, but from all recent accounts, it sounds like it will be at least
  55. a year before an ANSI standard exception handling extension is approved
  56. and implemented in enough C++ compilers to make it worthwhile.  Not that 
  57. operator new[] is likely to be approved and widely implemented in less 
  58. than a year, either.  
  59.  
  60. The point is just that implementation all of these "good" mechanisms for 
  61. handling the more egregious shortcomings in C++ are a long way off, and 
  62. there's an awful lot of code being written in the meantime for which 
  63. SOME error avoidance or handling conventions and idioms would be useful.
  64.  
  65. [Also, having worked on a large software system that used exceptions as
  66. a primary means of error reporting and recovery, I'm not convinced that 
  67. it's the panacea some people seem to think it will be.  Dealing with
  68. exceptions correctly in large systems rapidly becomes tedious and error
  69. prone itself.]
  70.