From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 837 invoked by alias); 9 Apr 2013 19:02:38 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 800 invoked by uid 55); 9 Apr 2013 19:02:34 -0000 From: "amalisperid at yahoo dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/56889] =delete(ing) default copy and move operations for a polymorphic type gives compilation error messages Date: Tue, 09 Apr 2013 19:02:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: amalisperid at yahoo dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2013-04/txt/msg00791.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D56889 --- Comment #4 from Amali Praveena 2013-04-0= 9 19:02:32 UTC --- Hi Jonathan, =C2=A0=C2=A0=C2=A0=C2=A0 The Stack in the example is an abstract type, so I= 'm explicitly saying that this abstract type cannot be copied or moved;=C2=A0but the derived cla= ss vector_stack, which provides implementation for this abstract type is copya= ble 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 provid= ed the clone function (clone pattern). This is what bjarne stroustrup says in his draft version of PL Fourth Editi= on, 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=E2=80=99t know what members the derived = class has (=C2=A73.3.3), so we can=E2=80=99t 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 de=EF=AC=81nitio= ns of those two operations: class Shape { public: Sha pe(const Sha pe&) =3Ddelete; // no copy operations Sha pe& opera tor=3D(const Sha pe&) =3Ddelete; Sha pe(Sha pe&&) =3Ddelete; // no move operations Sha pe& opera tor=3D(Shape&&) =3Ddelete; =CB=9CSha 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 (=C2=A722.2.= 4). In case you forgot to delete a copy or move operation, no harm is done. A m= ove operation is not implicitly generated for a class where the user has explicitly decla= red a destructor. Furthermore, the generation of copy operations are deprecated in this case (=C2=A742.2.3). This can be a good reason to explicitly de=EF=AC=81ne a des= tructor even where the compiler would have implicitly provided one (=C2=A717.2.3). The C++ Programming Language, 4th edition =C2=A92012 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 To: amalisperid@yahoo.com=20 Sent: Tuesday, 9 April 2013 10:26 PM Subject: [Bug c++/56889] =3Ddelete(ing) default copy and move operations fo= r a polymorphic type gives compilation error messages http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D56889 Jonathan Wakely changed: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 What=C2=A0 =C2=A0 |Removed=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |Added ---------------------------------------------------------------------------- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Status|UNCONFIRMED=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |RESOLVED =C2=A0 =C2=A0 =C2=A0 =C2=A0 Resolution|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |INVALID --- Comment #3 from Jonathan Wakely 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: 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: List-Archive: List-Post: List-Help: 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" 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: 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?id=56896 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= and --with-gxx-include-dir=/ 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-expand=30 --param ggc-min-heapsize=4096 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" Or: ~/gnu/gcc/trunk/tmp/gcc$ ./xgcc -B. ~/hw.cc --sysroot=/foo/bar 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);