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

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

[robert dot schweikert at abaqus dot com]

This may or may not be related to the fact that the argument being passed is a
template.

The copy ctor of the template is private and thus we get the compiler error.
Since the argument is passed straight through to the bass class ctor during
construction of the derived object I see no reason why the compiler would need
to invoke the copy constructor at this point.

I tested a relatively recent snapshot on IA32:

g++ (GCC) 3.4.0 20040319 (prerelease)

-> g++ -c rgnF_Property.i
/myPath/include/omu_Varray.h: In constructor
`rgnF_Property::rgnF_Property(ftr_FeatureList*, const omu_VarrayPtr&, const
omu_VarrayPtr&, const omu_VarrayPtr&, const omu_VarrayPtr&, omu_VarrayInt32&,
const cow_String&, cax_MigrationType, cax_MigrationType, cax_PropertyKind, uint32)':
/myPath/include/omu_Varray.h:52: error: `omu_Varray<T>::omu_Varray(const
omu_Varray<T>&) [with T = void*]' is private
/myPath/module/rgn/ftr/impl/rgnF_Property.C:87: error: within this context

-- 
           Summary: the copy constructor is called unnecessarily/incorrectly
                    when passing an arg by reference to the base class
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: robert dot schweikert at abaqus dot com
                CC: gcc-bugs at gcc dot gnu dot org,robert dot schweikert at
                    abaqus dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14823

[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]

------- Additional Comments From robert dot schweikert at abaqus dot com  2004-04-02 14:31 -------
Created an attachment (id=6033)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6033&action=view)
test case


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14823

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-02 14:47 -------
The call to the copy construtor is most likely not being done but it is required by the standard to be 
accessable.

Next time read <http://gcc.gnu.org/gcc-3.4/changes.html> as there are changes to G++ which make 
it more strict than most other C++ compilers sometimes:
When binding an rvalue of class type to a reference, the copy constructor of the class must be 
accessible. For instance, consider the following code:
        class A 
        {
        public:
          A();
          
        private:
          A(const A&);   // private copy ctor
        };
        
        A makeA(void);
        void foo(const A&);
        
        void bar(void)
        {
          foo(A());       // error, copy ctor is not accessible
          foo(makeA());   // error, copy ctor is not accessible
          
          A a1;
          foo(a1);        // OK, a1 is a lvalue
        }
This might be surprising at first sight, especially since most popular compilers do not correctly 
implement this rule  (further details: <http://gcc.gnu.org/bugs.html#cxx_rvalbind> ).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14823

[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]

------- Additional Comments From robert dot schweikert at abaqus dot com  2004-04-02 15:18 -------
Subject: Re:  the copy constructor is called
	unnecessarily/incorrectly when passing an arg by reference to the base class

This is not the same. I understand the example and why the copy ctor
must be accesible. However, In my case the compiler complains on
initialization of the base class with the same reference that was passed
to the derived class.

The structure is basically like this:

Taking a from the previous example:

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

class foo
{
    public:
      foo(const A&);
}

class bar : public foo
{
    public:
       bar(const &A);
}

bar::bar(const &A ola) : foo(ola)
{
}

void nutty(void)
{
   A a1;
   bar(a1);
}

In the test case the compiler does not complain about the instantiation
of bar, in this example, but about the initialization of foo during the
construction of bar. When foo is initialized during the construction of
bar the copy constructor should no longer come into play. I agree that
creating the temporary in nutty() meets the rules described in the
changes document. It must be possible to pass a reference to the base
class during class hierarchy initialization without the copy
constructor.

Thanks,
Robert

On Fri, 2004-04-02 at 09:47, pinskia at gcc dot gnu dot org wrote:
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-02 14:47 -------
> The call to the copy construtor is most likely not being done but it is required by the standard to be 
> accessable.
> 
> Next time read <http://gcc.gnu.org/gcc-3.4/changes.html> as there are changes to G++ which make 
> it more strict than most other C++ compilers sometimes:
> When binding an rvalue of class type to a reference, the copy constructor of the class must be 
> accessible. For instance, consider the following code:
>         class A 
>         {
>         public:
>           A();
>           
>         private:
>           A(const A&);   // private copy ctor
>         };
>         
>         A makeA(void);
>         void foo(const A&);
>         
>         void bar(void)
>         {
>           foo(A());       // error, copy ctor is not accessible
>           foo(makeA());   // error, copy ctor is not accessible
>           
>           A a1;
>           foo(a1);        // OK, a1 is a lvalue
>         }
> This might be surprising at first sight, especially since most popular compilers do not correctly 
> implement this rule  (further details: <http://gcc.gnu.org/bugs.html#cxx_rvalbind> ).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14823

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

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-04-02 17:41 -------
Robert, can you try to come up with a small example that shows your point? 
I understand that the testcase you posted does not demonstrate it (right?) 
but the big one attached to this PR is so complicated that I stopped 
looking at it after a few minutes... 
 
W. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14823

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-02 18:01 -------
No it is not complaining on that, it is complaining on:
typedef void* omu_Ptr;
typedef omu_Varray<omu_Ptr> omu_VarrayPtr;
....
 : rgnF_GeomSet (fl, vrec, erec, frec, crec, omu_VarrayPtr(),  <--- rvalue (omu_VarrayPtr () ), so you need 
to access the copy 
constror
   name, how_to_split,
          how_to_merge),

.... (before, the base class class constructor):
    rgnF_GeomSet (
 ftr_FeatureList*,
 const omu_VarrayPtr& vrec,
 const omu_VarrayPtr& erec,
 const omu_VarrayPtr& frec,
 const omu_VarrayPtr& crec,
 const omu_VarrayPtr& rrec,
 const cow_String& name,
 cax_MigrationType how_to_split = cax_SPLIT_COPY,
 cax_MigrationType how_to_merge = cax_MERGE_EXPAND);

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14823

[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]

------- Additional Comments From robert dot schweikert at abaqus dot com  2004-04-02 18:22 -------
Subject: Re:  the copy constructor is called
	unnecessarily/incorrectly when passing an arg by reference to the base class

On Fri, 2004-04-02 at 13:01, pinskia at gcc dot gnu dot org wrote:
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-02 18:01 -------
> No it is not complaining on that, it is complaining on:
> typedef void* omu_Ptr;
> typedef omu_Varray<omu_Ptr> omu_VarrayPtr;
> ....
>  : rgnF_GeomSet (fl, vrec, erec, frec, crec, omu_VarrayPtr(),  <--- rvalue (omu_VarrayPtr () ), so you need 
> to access the copy 
> constror

Nope, I disagree. I did look at the sections in the standard that the
changes page refers to and found the following:

"
A reference to type "cv1 T1" is initialized by an expression of type
"cv2 T2" as follows:

- If the initializer expression

  - is an lvalue ..... (clearly not the case here)

  - has a class type (i.e. T2 is a class type) and can be implicitly
converted to an lvalue of type "cv3 T3" where "cv1 T1" is
reference-compatible with "cv3 T3" (this conversion is selected by
enumerating the applicable conversion functions and choosing the best
one through overload resolution)

then the reference is bound directly to the initializer expression
lvalue in the first case, and the reference is bound to the lvalue
result of the conversion the second case. In these cases the reference
is said to bind directly to the initializer expression.......
"

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 (no copy constructor
needed) and the reference can then be bound directly to the lvalue that
results from the conversion. Whether or not the copy ctor is private
makes no difference in this case.

I will try and come up with a simpler example.

Thanks,
Robert

>    name, how_to_split,
>           how_to_merge),
> 
> .... (before, the base class class constructor):
>     rgnF_GeomSet (
>  ftr_FeatureList*,
>  const omu_VarrayPtr& vrec,
>  const omu_VarrayPtr& erec,
>  const omu_VarrayPtr& frec,
>  const omu_VarrayPtr& crec,
>  const omu_VarrayPtr& rrec,
>  const cow_String& name,
>  cax_MigrationType how_to_split = cax_SPLIT_COPY,
>  cax_MigrationType how_to_merge = cax_MERGE_EXPAND);


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14823

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

[giovannibajo at libero dot it]

------- 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? 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. 

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). Your 
first sub-bullet cannot be applied; 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?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14823

[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]

------- 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

[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]

------- Additional Comments From robert dot schweikert at abaqus dot com  2004-04-05 13:20 -------
Subject: Re:  the copy constructor is called
	unnecessarily/incorrectly when passing an arg by reference to the base class

On Fri, 2004-04-02 at 12:41, bangerth at dealii dot org wrote:
> ------- Additional Comments From bangerth at dealii dot org  2004-04-02 17:41 -------
> Robert, can you try to come up with a small example that shows your point? 
> I understand that the testcase you posted does not demonstrate it (right?) 
> but the big one attached to this PR is so complicated that I stopped 
> looking at it after a few minutes... 
>  
> W. 

Well,

I tried but failed. I have two simple test cases that have the same
schematics as the filed test case but neither produces the problem. Thus
the compiler must be getting confused by something else in the file.

Robert

----test1.C----

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

class foo
{
    public:
      foo(const A&, const A&);
};

class bar : public foo
{
    public:
       bar(const A&);
};

bar::bar(const A& ola) : foo(ola, A())
{
}

void nutty(void)
{
   A a1(void);
   bar B(A());
}


--- test2.C ----

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())
{
}





-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14823

[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]

------- Additional Comments From robert dot schweikert at abaqus dot com  2004-04-05 13:45 -------
Subject: Re:  the copy constructor is called
	unnecessarily/incorrectly when passing an arg by reference to the base class


Oops, I of course picked up the wrong compiler (gcc-3.3.) and the both
examples I sent previously reproduce the symptom if I use gcc-3.4.

Thanks,
Robert


On Fri, 2004-04-02 at 12:41, bangerth at dealii dot org wrote:
> ------- Additional Comments From bangerth at dealii dot org  2004-04-02 17:41 -------
> Robert, can you try to come up with a small example that shows your point? 
> I understand that the testcase you posted does not demonstrate it (right?) 
> but the big one attached to this PR is so complicated that I stopped 
> looking at it after a few minutes... 
>  
> W. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14823

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

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-04-05 13:49 -------
Subject: Re:  the copy constructor is called unnecessarily/incorrectly when passing an arg by reference to the base class

robert dot schweikert at abaqus dot com wrote:

>> 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.
>  [...]
> "
> - 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).

It says: "**IF** the initializer expression [...] has a class type and can be
implicitly converted to an lvalue [...] then the reference is bound directly"
(my stress). So we have an if-then clause. A temporary created by the explicit
function notation is a rvalue. How can it be converted to an lvalue? This is
what I asked. You didn't show me where the standard says that a rvalue of that
kind (or any kind) can be implicitly converted to a lvalue. There is no default
conversion to do so. So the "if" condition is false.

> 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.]

Yes, but we're speaking of binding to *lvalues*. Your initializer expression is
a rvalue. And there is no way it can be converted.

> Lets consider the following simple example:
> [...] yet this simple example compiles just fine.

I don't have time to analyze it properly, but by the looks of it it shouldn't
compile. If it does, it's a bug. Please, file a different bug report for this.

Giovanni Bajo




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14823

[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]

------- Additional Comments From robert dot schweikert at abaqus dot com  2004-04-07 13:57 -------
Subject: Re:  the copy constructor is called
	unnecessarily/incorrectly when passing an arg by reference to the base class

OK,

One more message on this subject. I have conferred with a few more
people and I was obviously confused. 

Sorry for taking up your time. Thanks for the clarifications you
provided and for your patience.

There is no bug, I will fix the code.

Thanks,
Robert

On Mon, 2004-04-05 at 09:49, giovannibajo at libero dot it wrote:
> ------- Additional Comments From giovannibajo at libero dot it  2004-04-05 13:49 -------
> Subject: Re:  the copy constructor is called unnecessarily/incorrectly when passing an arg by reference to the base class
> 
> robert dot schweikert at abaqus dot com wrote:
> 
> >> 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.
> >  [...]
> > "
> > - 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).
> 
> It says: "**IF** the initializer expression [...] has a class type and can be
> implicitly converted to an lvalue [...] then the reference is bound directly"
> (my stress). So we have an if-then clause. A temporary created by the explicit
> function notation is a rvalue. How can it be converted to an lvalue? This is
> what I asked. You didn't show me where the standard says that a rvalue of that
> kind (or any kind) can be implicitly converted to a lvalue. There is no default
> conversion to do so. So the "if" condition is false.
> 
> > 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.]
> 
> Yes, but we're speaking of binding to *lvalues*. Your initializer expression is
> a rvalue. And there is no way it can be converted.
> 
> > Lets consider the following simple example:
> > [...] yet this simple example compiles just fine.
> 
> I don't have time to analyze it properly, but by the looks of it it shouldn't
> compile. If it does, it's a bug. Please, file a different bug report for this.
> 
> Giovanni Bajo


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14823

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-27 08:48 -------
bug 12226.

*** This bug has been marked as a duplicate of 12226 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14823

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-27 08:47 -------
Reopening bug to mark as a dup of ...

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14823