home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / cplus / 16037 < prev    next >
Encoding:
Text File  |  1992-11-10  |  2.1 KB  |  59 lines

  1. Path: sparky!uunet!munnari.oz.au!jabaru.cec.edu.au!csource!david
  2. From: david@csource.oz.au (david nugent)
  3. Newsgroups: comp.lang.c++
  4. Subject: Default constructors
  5. Message-ID: <11RDwB1w165w@csource.oz.au>
  6. Date: Tue, 10 Nov 92 12:27:47 +1100
  7. Reply-To: david@csource.oz.au
  8. Organization: Unique Computing Pty Ltd, Melbourne, Australia
  9. Lines: 48
  10.  
  11. I've stumbled on an annoying difference in C++ implementations in the
  12. generation of default constructors and copy constructors. In particular,
  13. gcc seems to have problems when an explicit call is made to a default
  14. constructor, whereas other compilers I use have no problem with this.
  15. On reading through ARM, I can't determine which is the 'correct'
  16. behaviour, so any comments would be welcome.
  17.  
  18. Here's some code which demonstrates the problem:
  19.  
  20.  class X
  21.     {
  22.     int member1;
  23.     char member2[2];
  24.     };
  25.  
  26.  class Y : public X
  27.     {
  28.  
  29.     public:
  30.         Y () : X () {}
  31.         Y (const X& a) : X (a) {}
  32.     };
  33.  
  34. gcc (2.2.2) won't compile this.  Several other compilers I use have
  35. no problems.  I also note that gcc has no problems initialising the
  36. basic built-in types with constructor syntax (eg. int x(1);) yet it
  37. still has problems explicitly calling the default constructor/copy
  38. constructor for class X as above.  But it does 'call' the generated
  39. functions implicitly as required.
  40.  
  41. It is annoying because it is often quite convenient to derive classes
  42. from existing structures defined in C header files, making use of
  43. the ability to attach additional data and functionality, and yet use
  44. those same objects with C library calls (eg. formating information
  45. on 'struct tm' etc.); and in cases where the above syntax is accepted,
  46. using a simple assignment in the derived class' constructure is
  47. inefficient because it causes the default constructor or copy
  48. constructor to be called twice.
  49.  
  50. Responses by email please - I'll summarise to the group if there is
  51. any interest.
  52.  
  53.  
  54.  
  55. Smoke me a kipper, Skipper - I'll be back for breakfast! - "Ace" Rimmer
  56. david@csource.oz.au 3:632/348@fidonet 58:4100/1@intlnet 199:4242/5@rainbownet
  57. Unique Computing P/L / Communications+LAN Specialists / Public Access USENET
  58. PO Box 352, Doveton, VIC, Aust 3144. Data/BBS: +61-3-792-3507 / +61-3-794-7949
  59.