From 2205104066732089786 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,5e69b3c02624e7d0 X-Google-Attributes: gidf78e5,public From: Francis Glassborow Subject: Re: A C++ asymmetry Date: 1999/09/13 Message-ID: #1/1 X-Deja-AN: 524559758 Approved: stephen.clamage@sun.com (comp.std.c++) References: X-UID: 0000000001 X-Status: $$$T Organization: Southfield Microcomputer SS Mime-Version: 1.0 Reply-To: Francis Glassborow Newsgroups: comp.std.c++ Originator: clamage@taumet In article , Aldo Aleardi writes >I do not understand this behavior: after all the state of a default >constructed object could be modified by the member functions >so that the copy of an object would make sense etc. etc... >Just out of curiosity. Actually it took me several years to even realise that a default copy ctor did inhibit compiler generation of a default ctor. Actually you are thinking of copy ctors (there are possibly four of them) and other ctors as being disjoint sets. This is not the case as a copy ctor can be produced by defaulting 2nd and subsequent parameters for a ctor whose first parameter is a reference to a, possibly cv qualified, instance of the class. The actual rule is simple. A compiler generated default ctor is only available if no ctors have been provided. Now it is not unreasonable that a class has a non-copy ctor provided when the compiler generated copy ctor would be entirely safe and do exactly what you expect (and possibly do so more efficiently than a programmer can write - as the compiler knows what the copy ctor does it can optimise very aggressively) However it seems difficult to imagine a case where a user written copy ctor was needed but a compiler generated default ctor would do the right thing. Would you like to provide a counter example? Without one it seems that the standard is entirely correct in this asymmetry. Francis Glassborow Journal Editor, Association of C & C++ Users 64 Southfield Rd Oxford OX4 1PA +44(0)1865 246490 All opinions are mine and do not represent those of any organisation [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]