From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4608 invoked by alias); 5 Apr 2004 13:17:35 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 4588 invoked by alias); 5 Apr 2004 13:17:29 -0000 Date: Mon, 05 Apr 2004 13:17:00 -0000 Message-ID: <20040405131729.4587.qmail@sources.redhat.com> From: "robert dot schweikert at abaqus dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040402143013.14823.robert.schweikert@abaqus.com> References: <20040402143013.14823.robert.schweikert@abaqus.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/14823] the copy constructor is called unnecessarily/incorrectly when passing an arg by reference to the base class X-Bugzilla-Reason: CC X-SW-Source: 2004-04/txt/msg00407.txt.bz2 List-Id: ------- Additional Comments From robert dot schweikert at abaqus dot com 2004-04-05 13:17 ------- Subject: Re: the copy constructor is called unnecessarily/incorrectly when passing an arg by reference to the base class On Sat, 2004-04-03 at 12:07, giovannibajo at libero dot it wrote: > ------- Additional Comments From giovannibajo at libero dot it 2004-04-03 17:07 ------- > (In reply to comment #6) > > > The text can be found in the first sub bullet of bullet 5 in section > > 8.5.3 and IMHO this is the case that applies here as the rvalue of > > omu_VarrayPtr() can be converted to an lvalue > > Where exactly does the standard speak of a rvalue-to-lvalue conversion? That would be on page 147 in the [dcl.init.ref] section (8.5.3) bullet 5. > There > is a lvalue-to-rvalue conversion which happens when lvalues appear in contexts > in which rvalues are expected (see [basic.lval]/7, and [conv.lval]), but not > the other way round. Well it reads " - has a class type (i.e. T2 is a class type) and can be implicitly converted to an lvalue .... " So T2 in this case would be the rvalue and the reference would be bound to the result of the conversion (lvalue). At the end of the page one can find the following note: " [Note the usual lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are not needed, and therefore are suppressed, when such direct bindings to lvalues are done.] " > > If any rvalue could be converted to a lvalue and vice versa, why would we have > a difference in the first place? > > The expression omu_VarrayPtr() is an rvalue, period ([basic.lval]/6). No argument there. > Your > first sub-bullet cannot be applied; Correct I am not saying it should. > you have to look into the rvalue case, > which is covered by bullet 2, sub-bullet 1 (as referenced in the bugs.html > page). > > Now, this must be the 5th time I answer this. What on earth do we have to do > more than adding a FAQ, as we already did? Well, I am not sure about that. I know repetitive questions can be frustrating. Lets consider the following simple example: template class AT { public: AT(); virtual T& getType(); virtual ~AT(); private: AT(const AT&); // private copy ctor }; class A { public: A(); virtual ~A(); private: A(const A&); // private copy ctor }; typedef AT ATuse; class foo { public: foo(const ATuse&, const ATuse&); }; class bar : public foo { public: bar(const ATuse&); }; bar::bar(const ATuse& ola) : foo(ola, ATuse()) { } ATuse() in the initialization of the foo base class in the bar ctor is an rvalue and the foo ctor expects a const ref as the second argument. Both copy constructors (template, and the type used for the template) are private, yet the code compiles just fine. The schematics are the same as in the test case (i file attached to the bug report), yet this simple example compiles just fine. This indicates to me that the compiler is getting confused by something and that the direct binding as described in bullet 5 sub bullet 2 in section 8.5.3 actually works. I have not thought about how to track down the point where the compiler is getting confused. Thanks, Robert -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14823