Bug 164141 - g++ requires public copy constructor (ctor)
Summary: g++ requires public copy constructor (ctor)
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc   
(Show other bugs)
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-25 11:13 UTC by Graham Hudspith
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-07-26 09:55:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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 11:14 UTC, Graham Hudspith
no flags Details

Description Graham Hudspith 2005-07-25 11:13:03 UTC
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):

How reproducible:

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 11:14:00 UTC
Created attachment 117117 [details]
Sample test program.

Comment 2 Graham Hudspith 2005-07-25 11:17:04 UTC
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 09:52:05 UTC
Sigh! Better kill off this bug report! Just found this in the GCC v3.4 release


and the "non BUGS" webpage:


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 

  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 10:03:58 UTC
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.