home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12781 < prev    next >
Encoding:
Text File  |  1992-08-23  |  1.8 KB  |  38 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!centerline!matt
  3. From: matt@centerline.com (Matt Landau)
  4. Subject: Re: constructor call during initialization of same class
  5. Message-ID: <matt.714605642@centerline.com>
  6. Sender: news@centerline.com
  7. Nntp-Posting-Host: rapier
  8. Organization: CenterLine Software, Inc.
  9. References: <1992Aug23.030355.23047@athena.mit.edu> <1992Aug23.154530.1131@taumet.com>
  10. Date: Sun, 23 Aug 1992 21:34:02 GMT
  11. Lines: 25
  12.  
  13. In <1992Aug23.154530.1131@taumet.com> steve@taumet.com (Steve Clamage) writes:
  14. >I am guessing that you want to share some code by having several
  15. >constructors call a "basic" constructor.  You can't do that with
  16. >a construcutor.  You can write an initialization function which all
  17. >constructors call.  
  18.  
  19. Yes, you can, but it's not quite the same semantically.  In particular,
  20. using initalization functions means you cannot initialize data members
  21. that are references, and you cannot initialize data members that are
  22. instances of classes by using their copy constructors.  (You end up
  23. using their assignment operators instead if assign to them in your 
  24. shared initialization member function.)
  25.  
  26. More properly, of course you CAN initialize references and perform copy
  27. construction of data members that are instances, but you have to do it
  28. by using the usual data member initialization syntax, and you have to
  29. do it explicitly in every overloading of the constructor.  Where there
  30. are a large number of such data members, or when the class design is
  31. very fluid (early in the design, for instance), it's very easy to miss
  32. one or two of these.
  33.  
  34. I think THAT is the problem the original poster was trying to address;
  35. it's a problem that being able to call alternate overloadings of your
  36. own constructor would address.  Are there any ways to deal with it in
  37. the language as currently defined?
  38.