home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 17926 < prev    next >
Encoding:
Text File  |  1992-12-14  |  1.5 KB  |  47 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!gatech!news.byu.edu!hamblin.math.byu.edu!sol.ctr.columbia.edu!spool.mu.edu!umn.edu!csus.edu!borland.com!pete
  3. From: pete@borland.com (Pete Becker)
  4. Subject: Re: Overriding the order of constructors?
  5. Message-ID: <1992Dec14.181823.6474@borland.com>
  6. Originator: pete@genghis.borland.com
  7. Keywords: constructor ordering
  8. Sender: news@borland.com (News Admin)
  9. Organization: Borland International
  10. References: <1992Dec13.220943.22047@jarvis.csri.toronto.edu> <robison1.724307343@husc10>
  11. Date: Mon, 14 Dec 1992 18:18:23 GMT
  12. Lines: 33
  13.  
  14. In article <robison1.724307343@husc10> robison1@husc10.harvard.edu (Keith Robison) writes:
  15. >dembo@csri.toronto.edu (Prof. Ron Dembo) writes:
  16. >
  17. >
  18. >
  19. >>What is the rational for not allowing a programmer to override the
  20. >>default calling order of constructors and initializers?  I see
  21. >>the importance of having a well defined default.  However, why
  22. >>shouldn't the ordering of the initilizers be significant?  
  23. >
  24. >
  25. >    I believe you can effectively accomplish this dangerous
  26. >goal by calling virtual functions in your constructors:
  27. >
  28. >
  29. >class A {
  30. >  A() { reroute(); do_A_ctor_stuff(); }
  31. >  virtual void reroute(); { }
  32. >}
  33. >
  34. >class B : public A {
  35. >  B() {}
  36. >  void reroute ()  { do_B_ctor_stuff(); }
  37. >}
  38. >
  39. >
  40. >This will cause B's reroute() to be executed before any 
  41. >A constructing has occurred.
  42. >
  43.  
  44.     This won't work.  Virtual functions are effectively non-virtual when
  45. called from a constructor or a destructor.  If they weren't, you could call
  46. a member function on an uninitialized object.
  47.