home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 17937 < prev    next >
Encoding:
Text File  |  1992-12-14  |  2.6 KB  |  75 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!spool.mu.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!uunet.ca!ohrd!twriter
  3. From: twriter@rd.hydro.on.ca (Timothy Writer)
  4. Subject: Re: Overriding the order of constructors?
  5. Message-ID: <1992Dec14.204903.10047@rd.hydro.on.ca>
  6. Keywords: constructor ordering
  7. Reply-To: twriter@rd.hydro.on.ca
  8. Organization: "Ontario Hydro - Research Division"
  9. References: <1992Dec13.220943.22047@jarvis.csri.toronto.edu> <robison1.724307343@husc10> <Bz8oGx.B7x@well.sf.ca.us>
  10. Date: Mon, 14 Dec 92 20:49:03 GMT
  11. Lines: 62
  12.  
  13. johnrp@well.sf.ca.us (John Panzer) writes:
  14.  
  15. >In article <robison1.724307343@husc10> robison1@husc10.harvard.edu (Keith Robison) writes:
  16. >>dembo@csri.toronto.edu (Prof. Ron Dembo) writes:
  17. >>
  18. >>
  19. >>
  20. >>>What is the rational for not allowing a programmer to override the
  21. >>>default calling order of constructors and initializers?  I see
  22. >>>the importance of having a well defined default.  However, why
  23. >>>shouldn't the ordering of the initilizers be significant?  
  24. >>
  25. >>
  26. >>    I believe you can effectively accomplish this dangerous
  27. >>goal by calling virtual functions in your constructors:
  28. >>
  29. >>
  30. >>class A {
  31. >>  A() { reroute(); do_A_ctor_stuff(); }
  32. >>  virtual void reroute(); { }
  33. >>}
  34. >>
  35. >>class B : public A {
  36. >>  B() {}
  37. >>  void reroute ()  { do_B_ctor_stuff(); }
  38. >>}
  39. >>
  40. >>
  41. >>This will cause B's reroute() to be executed before any 
  42. >>A constructing has occurred.
  43. >>
  44.  
  45. >Are you certain?  I believe that A::reroute() will
  46. >be called if reroute() is called from within A's
  47. >constructor or destructor.  I think this is a
  48. >common C++ "gotcha" - it's certainly gotten me
  49. >in the past.
  50.  
  51. You (robison1@husc10.harvard.edu) are right.  To quote from the ARM p.294:
  52.  
  53.     Member functions may be called in constructors and destructors.
  54.     This implies that virtual functions may be called (directly or
  55.     indirectly).  The function called will be the one defined in the
  56.     constructor's (or destructor's) OWN class or its bases, but NOT
  57.     any function overriding it in a derived class.  This ensures
  58.     that unconstructed objects will not be accessed during
  59.     construction or destruction.
  60.  
  61. In other words, although your (dembo@csri.toronto.edu) example is
  62. syntactically correct, it does not have the desired result.
  63.  
  64. Perhaps the original poster could porovide a more concrete example of
  65. what he hopes to achieve by specifying the order of constructor
  66. execution.  Someone may be able to suggest an alternative solution.
  67.  
  68. Tim
  69.  
  70. -- 
  71. Tim Writer                 phone:  (416) 231-4111 ext. 6990
  72. Ontario Hydro Research Division         fax:    (416) 237-9285
  73. Toronto, Ontario             e-mail: twriter@rd.hydro.on.ca
  74. CANADA
  75.