[Bug c++/14823] the copy constructor is called unnecessarily/incorrectly when passing an arg by reference to the base class

["robert dot schweikert at abaqus dot com" <gcc-bugzilla@gcc.gnu.org>]

------- 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 T>
class AT
{
public:
    AT();
    virtual T& getType();
    virtual ~AT();
private:
    AT(const AT<T>&); // private copy ctor
};


class A
{
public:
    A();
    virtual ~A();
private:
    A(const A&);  // private copy ctor
};

typedef AT<A> 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