Bug 164141 - g++ requires public copy constructor (ctor)
g++ requires public copy constructor (ctor)
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-25 07:13 EDT by Graham Hudspith
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-26 05:55:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Sample test program. (367 bytes, text/x-c++src)
2005-07-25 07:14 EDT, Graham Hudspith
no flags Details

  None (edit)
Description Graham Hudspith 2005-07-25 07:13:03 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
Define a class with a private copy-ctor and the code refuses to compile in situations where the copy-ctor is not even required (I believe).

I'll attach a test-case in a moment.

This occurs in the case of a third-party add-on (I'll spare their blushes) which comes with source-code. The code compiles with g++ v3.2.x and v3.3.x but fails under g++ v3.4.x, v4.0.0 and (latest from fc4 updates-testing) v4.0.1.

Construct an instance of a class and pass this as a const-ref to a function, everything is okay.

Call function again and construct an instance of the class as one of the arguments to the function, and the compile fails.

What is also annoying is that if I make the copy-ctor public, the code compiles but then DOES NOT call the copy-ctor! It just needs the copy-ctor to be declared as public ...


Version-Release number of selected component (if applicable):
gcc-c++-4.0.0-8

How reproducible:
Always

Steps to Reproduce:
1. g++ -o privateCtor -O0 -g privateCtor.cpp
2. compile succeeds
3. g++ -DNEED_COPY_CTOR -o privateCtor -O0 -g privateCtor.cpp
4. compile fails

Additional info:
Comment 1 Graham Hudspith 2005-07-25 07:14:00 EDT
Created attachment 117117 [details]
Sample test program.
Comment 2 Graham Hudspith 2005-07-25 07:17:04 EDT
Sigh! In my "Steps to Reproduce", above, please swap steps 1 and 3 ...

1. g++ -DNEED_COPY_CTOR -o privateCtor -O0 -g privateCtor.cpp
2. compile succeeds
3. g++ -o privateCtor -O0 -g privateCtor.cpp
4. compile fails
Comment 3 Graham Hudspith 2005-07-26 05:52:05 EDT
Sigh! Better kill off this bug report! Just found this in the GCC v3.4 release
notes:

http://gcc.gnu.org/gcc-3.4/changes.html

and the "non BUGS" webpage:

http://gcc.gnu.org/bugs.html#cxx_rvalbind

I'll send this off to the third-party add-on people too. Sorry for any wasted
time you've spent on this ...

------------ snip snip ------------

Copy constructor access check while initializing a reference.

Consider this 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
}

    Starting with GCC 3.4.0, binding an rvalue to a const reference requires an
accessible copy constructor. This might be surprising at first sight, especially
since most popular compilers do not correctly implement this rule.

    The C++ Standard says that a temporary object should be created in this
context and its contents filled with a copy of the object we are trying to bind
to the reference; it also says that the temporary copy can be elided, but the
semantic constraints (eg. accessibility) of the copy constructor still have to
be checked.

    For further information, you can consult the following paragraphs of the C++
standard: [dcl.init.ref]/5, bullet 2, sub-bullet 1, and [class.temporary]/2.
Comment 4 Graham Hudspith 2005-07-26 06:03:58 EDT
Spooky how close my sample test program was to the GNU example :-)

Note You need to log in before you can comment on or make changes to this bug.