C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  private operator= and copy construction          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Phlip Guest Posted: Fri Oct 15, 2004 11:29 am    Post subject: private operator= and copy construction C++ dudes: class Foo { Foo &operator=(Foo const &); }; int main() { Foo f = Foo(); } I have this friend who swears on a stack he read a "Bug++ of the Month" article, in WJD, last decade, that quoted one Philip Staite as saying that code is ill-formed. My friend knows that = at initialization time calls the copy constructor, which for Foo is implicit. He claims Philip Staite claimed that the compiler would check the access of =, and forbid the statement, even though we all know the statement would have called the copy constructor, which is not private. I have attempted to read the Standard, but I don't have the latest one, and I have a macaque-level attention span. Who's right, my friend, or everyone else in our close-knit community? (Right about the language law, and right about the Bug++ article?) -- Phlip http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ron Natalie Guest Posted: Fri Oct 15, 2004 11:05 pm    Post subject: Re: private operator= and copy construction Phlip wrote: Quote: I have attempted to read the Standard, but I don't have the latest one, and I have a macaque-level attention span. Who's right, my friend, or everyone else in our close-knit community? (Right about the language law, and right about the Bug++ article?) As we have pointed out to you numerous times in the unmoderated group. It doesn't matter what "version" of the standard you are using. C++ was NEVER designed to work the way your "friend" claims. The 1999 and 2003 versions of the standards (as well as the ARM and all the drafts that I know about), don't ocnsider this an assignment. The standard says that when you do an initialization like this, the appropriate constructor is selected via the normal overload rules (yielding, in this case the copy constructor), and that is ALL that matters. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Howard Guest Posted: Fri Oct 15, 2004 11:18 pm    Post subject: Re: private operator= and copy construction "Phlip" <phlip_cpp (AT) yahoo (DOT) com> wrote Quote: C++ dudes: class Foo { Foo &operator=(Foo const &); }; int main() { Foo f = Foo(); } I have this friend who swears on a stack he read a "Bug++ of the Month" article, in WJD, last decade, that quoted one Philip Staite as saying that code is ill-formed. My friend knows that = at initialization time calls the copy constructor, which for Foo is implicit. He claims Philip Staite claimed that the compiler would check the access of =, and forbid the statement, even though we all know the statement would have called the copy constructor, which is not private. I have attempted to read the Standard, but I don't have the latest one, and I have a macaque-level attention span. Who's right, my friend, or everyone else in our close-knit community? (Right about the language law, and right about the Bug++ article?) Is he claiming that it *should* reject it, or that some specific compiler *does* reject it? I've got CodeWarrior 9.3, and it accepts that code fine. That doesn't mean squat about what the standard says, of course. :-) -Howard [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Maxim Yegorushkin Guest Posted: Fri Oct 15, 2004 11:24 pm    Post subject: Re: private operator= and copy construction Phlip <phlip_cpp (AT) yahoo (DOT) com> wrote: Quote: C++ dudes:    class Foo {   Foo &operator=(Foo const &); }; int main() {    Foo f = Foo(); } I have this friend who swears on a stack he read a "Bug++ of the Month" article, in WJD, last decade, that quoted one Philip Staite as saying  that code is ill-formed. No, the code in fact is well formed, see bellow. Quote: My friend knows that = at initialization time calls the copy constructor, which for Foo is implicit. He claims Philip Staite claimed that the  compiler would check the access of =, and forbid the statement, even though we all know the statement would have called the copy constructor, which is not private. Your friend is wrong. Initialization using = is a copy initialization,  which never considers using operator=. The relevant standard's wording is  in 8.15.14. <quote> If the destination type is a (possibly cvqualified) class type: ââ,¬" If the class is an aggregate (8.5.1), and the initializer is a  braceenclosed list, see 8.5.1. ââ,¬" If the initialization is directinitialization, or if it is  copyinitialization where the cvunqualified version of the source type is  the same class as, or a derived class of, the class of the destination,  constructors are considered. The applicable constructors are enumerated  (13.3.1.3), and the best one is chosen through overload resolution (13.3).  The constructor so selected is called to initialize the object, with the  initializer expression(s) as its argument(s). If no constructor applies,  or the overload resolution is ambiguous, the initialization is illformed. ââ,¬" Otherwise (i.e., for the remaining copyinitialization cases),  userdefined conversion sequences that can convert from the source type to  the destination type or (when a conversion function is used) to a derived  class thereof are enumerated as described in 13.3.1.4, and the best one is  chosen through overload resolution (13.3). If the conversion cannot be  done or is ambiguous, the initialization is illformed. The function  selected is called with the initializer expression as its argument; if the  function is a constructor, the call initializes a temporary of the  destination type. The result of the call (which is the temporary for the  constructor case) is then used to directinitialize, according to the rules  above, the object that is the destination of the copyinitialization. In  certain cases, an implementation is permitted to eliminate the copying  inherent in this directinitialization by constructing the intermediate  result directly into the object being initialized; see 12.2, 12.8. </quote> -- Maxim Yegorushkin [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Markus Moll Guest Posted: Sat Oct 16, 2004 10:10 am    Post subject: Re: private operator= and copy construction Hi Maxim Yegorushkin wrote: Quote: In  certain cases, an implementation is permitted to eliminate the copying  inherent in this directinitialization by constructing the intermediate  result directly into the object being initialized; see 12.2, 12.8. You should also give 12.2 (I think that's what the OP's friend is alluding to): 12.2 Temporary Objects [...] Even when the creation of the temporary object is avoided (12., all the semantic restrictions must be respected as if the temporary object was created. [ Example: even if the copy constructor is not called, all the semantic restrictions, such as accessibility (clause 11), shall be satisfied. ] Markus [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Phlip Guest Posted: Sun Oct 17, 2004 1:34 am    Post subject: Re: private operator= and copy construction Markus Moll wrote: Quote: 12.2 Temporary Objects [...] Even when the creation of the temporary object is avoided (12., all the semantic restrictions must be respected as if the temporary object was created. [ Example: even if the copy constructor is not called, all the semantic restrictions, such as accessibility (clause 11), shall be satisfied. ] Philip Staite submitted a Bug++ of the Month to WDJ, before August 1999. I know because I discussed it here: http://groups.google.com/groups?selm=7s7vuf%24mjh%40journal.concentric.n et That's the only citation for the article I can Google. However, nobody can back it up, so maybe Philip misunderstood that "clause", and WDJ just filled their Bug++ slot for that month. -- Phlip http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jon Sturgeon Guest Posted: Thu Oct 21, 2004 4:41 pm    Post subject: Re: private operator= and copy construction On 15 Oct 2004 07:29:12 -0400, "Phlip" <phlip_cpp (AT) yahoo (DOT) com> wrote: Quote: My friend knows that = at initialization time calls the copy constructor, which for Foo is implicit. He claims Philip Staite claimed that the compiler would check the access of =, and forbid the statement, even though we all know the statement would have called the copy constructor, which is not private. I think maybe what your friend is getting mixed up about is the difference between the semantics of object initialization using the '=' and '()' syntaxes. This was explained (much more eloquently that I can still hope to achieve) by James Kanze in one of my favorite C++ Usenet postings: http://groups.google.com/groups?selm=KANZE.93Aug12183142%40slsvhdt.us- es.sel.de Hope this helps. Jon Sturgeon [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.