[Bug c++/56889] =delete(ing) default copy and move operations for a polymorphic type gives compilation error messages

["amalisperid at yahoo dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #4 from Amali Praveena <amalisperid at yahoo dot com> 2013-04-09 19:02:32 UTC ---
Hi Jonathan,
     The Stack in the example is an abstract type, so I'm explicitly saying
that this abstract type cannot be copied or moved; but the derived class
vector_stack, which provides implementation for this abstract type is copyable
through clone function. Since the compiler won't know to which more derived
class the Stack points to at run time and so it cannot copy it, I've provided
the clone function (clone pattern).

This is what bjarne stroustrup says in his draft version of PL Fourth Edition,
as I quoted before.
Here is that section from the book.
3.3.4 Prev enting Copy and Move [tour2.copy.hier]
Using the default copy or move for a class in a hierarchy is typically a
disaster: Given only
a pointer to a base, we simply don’t know what members the derived class has
(§3.3.3), so
we can’t know how to copy them. So, the best thing to do is usually to delete
the default
copy and move operations; that is, to eliminate to default definitions of those
two operations:
class Shape {
public:
Sha pe(const Sha pe&) =delete; // no copy operations
Sha pe& opera tor=(const Sha pe&) =delete;
Sha pe(Sha pe&&) =delete; // no move operations
Sha pe& opera tor=(Shape&&) =delete;
˜Sha pe();
// ...
};
Now an attempt to copy a Sha pe will be caught by the compiler. If you need to
copy an
object in a class hierarchy, write some kind of clone function (§22.2.4).
In case you forgot to delete a copy or move operation, no harm is done. A move
operation
is not implicitly generated for a class where the user has explicitly declared
a destructor.
Furthermore, the generation of copy operations are deprecated in this case
(§42.2.3). This can be a good reason to explicitly define a destructor even
where the compiler
would have implicitly provided one (§17.2.3).
The C++ Programming Language, 4th edition ©2012 by Pearson Education, Inc.
Reproduced in draft form with the permission of the publisher. D R A F T

Thanks,
Amali.


________________________________
 From: redi at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
To: amalisperid@yahoo.com 
Sent: Tuesday, 9 April 2013 10:26 PM
Subject: [Bug c++/56889] =delete(ing) default copy and move operations for a
polymorphic type gives compilation error messages


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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-04-09
12:26:18 UTC ---
As Daniel says, you're missing a default constructor.

And if you define the type as non-copyable then obviously you can't copy it.

This is not a GCC bug.
>From gcc-bugs-return-419647-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Apr 09 19:08:58 2013
Return-Path: <gcc-bugs-return-419647-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3842 invoked by alias); 9 Apr 2013 19:08:58 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 3798 invoked by uid 48); 9 Apr 2013 19:08:53 -0000
From: "rmansfield at qnx dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/56896] New: Missing DIR_SEPARATOR if --with-gxx-include-dir configured as subdir of sysroot
Date: Tue, 09 Apr 2013 19:08:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rmansfield at qnx dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56896-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg00792.txt.bz2
Content-length: 4860


http://gcc.gnu.org/bugzilla/show_bug.cgi?idV896

             Bug #: 56896
           Summary: Missing DIR_SEPARATOR if --with-gxx-include-dir
                    configured as subdir of sysroot
    Classification: Unclassified
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: rmansfield@qnx.com


If gcc is configured with --with-sysroot=<path> and
--with-gxx-include-dir=<path>/<subpath> then gcc_gxx_include_dir will end up as
a relative path, and then incpath.c will trip the trailing sysroot
DIR_SEPARATOR and construct an invalid path.

e.g.

~/gnu/gcc/trunk/tmp/gcc$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c++ --disable-bootstrap
--with-gxx-include-dir=/home/ryan/foo/bar/usr/include/4.9.0
--with-sysroot=/home/ryan/foo/bar/
Thread model: posix
gcc version 4.9.0 20130409 (experimental) [trunk revision 197644] (GCC)
## --------- ##
## Platform. ##
~/gnu/gcc/trunk/tmp$ grep -nr gcc_gxx_include_dir *
gcc/Makefile:623:gcc_gxx_include_dir = usr/include/4.9.0
gcc/Makefile:624:gcc_gxx_include_dir_add_sysroot = 1
gcc/Makefile:1108:    "gxx_include_dir=$(gcc_gxx_include_dir)" \
gcc/Makefile:4055:  -DGPLUSPLUS_INCLUDE_DIR=\"$(gcc_gxx_include_dir)\" \
gcc/Makefile:4056:
-DGPLUSPLUS_INCLUDE_DIR_ADD_SYSROOT=$(gcc_gxx_include_dir_add_sysroot) \
gcc/Makefile:4057:
-DGPLUSPLUS_TOOL_INCLUDE_DIR=\"$(gcc_gxx_include_dir)/$(target_noncanonical)\"
\
gcc/Makefile:4058:
-DGPLUSPLUS_BACKWARD_INCLUDE_DIR=\"$(gcc_gxx_include_dir)/backward\" \
gcc/config.log:6339:gcc_gxx_include_dir='usr/include/4.9.0'
gcc/config.log:6340:gcc_gxx_include_dir_add_sysroot='1'
gcc/config.status:682:S["gcc_gxx_include_dir_add_sysroot"]="1"
gcc/config.status:683:S["gcc_gxx_include_dir"]="usr/include/4.9.0"


~/gnu/gcc/trunk/tmp/gcc$ ./xgcc -B. ~/hw.cc -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c++ --disable-bootstrap
--with-gxx-include-dir=/home/ryan/foo/bar/usr/include/4.9.0
--with-sysroot=/home/ryan/foo/bar/
Thread model: posix
gcc version 4.9.0 20130409 (experimental) [trunk revision 197644] (GCC)
COLLECT_GCC_OPTIONS='-B' '.' '-v' '-mtune=generic' '-march=x86-64'
 ./cc1plus -quiet -v -iprefix
/home/ryan/gnu/gcc/trunk/tmp/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/
-isystem ./include -isystem ./include-fixed -D_GNU_SOURCE /home/ryan/hw.cc
-quiet -dumpbase hw.cc -mtune=generic -march=x86-64 -auxbase hw -version -o
/tmp/cclOMQFL.s
GNU C++ (GCC) version 4.9.0 20130409 (experimental) [trunk revision 197644]
(x86_64-unknown-linux-gnu)
    compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand0 --param ggc-min-heapsize@96
ignoring nonexistent directory
"/home/ryan/gnu/gcc/trunk/tmp/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include"
ignoring nonexistent directory
"/home/ryan/gnu/gcc/trunk/tmp/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include-fixed"
ignoring nonexistent directory
"/home/ryan/gnu/gcc/trunk/tmp/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/include"
ignoring nonexistent directory "/home/ryan/foo/barusr/include/4.9.0"
ignoring nonexistent directory
"/home/ryan/foo/barusr/include/4.9.0/x86_64-unknown-linux-gnu"
ignoring nonexistent directory "/home/ryan/foo/barusr/include/4.9.0/backward"
<snip>

Or:

~/gnu/gcc/trunk/tmp/gcc$ ./xgcc -B. ~/hw.cc --sysroot=/foo/bar
<snip>
ignoring nonexistent directory "/foo/barusr/include/4.9.0"
ignoring nonexistent directory
"/foo/barusr/include/4.9.0/x86_64-unknown-linux-gnu"
ignoring nonexistent directory "/foo/barusr/include/4.9.0/backward"

I'm not sure if the following is sufficient, or if the gcc_gxx_include_dir
should never end up without a leading DIR_SEPARATOR.

Index: gcc/incpath.c
==================================================================--- gcc/incpath.c    (revision 197644)
+++ gcc/incpath.c    (working copy)
@@ -179,7 +179,8 @@
           char *sysroot_no_trailing_dir_separator = xstrdup (sysroot);
           size_t sysroot_len = strlen (sysroot);

-          if (sysroot_len > 0 && sysroot[sysroot_len - 1] == DIR_SEPARATOR)
+          if (sysroot_len > 0 && sysroot[sysroot_len - 1] == DIR_SEPARATOR
+          && p->fname[0] == DIR_SEPARATOR)
         sysroot_no_trailing_dir_separator[sysroot_len - 1] = '\0';
           str = concat (sysroot_no_trailing_dir_separator, p->fname, NULL);
           free (sysroot_no_trailing_dir_separator);