From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42589 invoked by alias); 5 Oct 2016 00:06:05 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 42572 invoked by uid 89); 5 Oct 2016 00:06:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=gdbtesters, compromise, super X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 05 Oct 2016 00:05:54 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 76A2C2F2F9E; Wed, 5 Oct 2016 00:05:53 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9505puj017902; Tue, 4 Oct 2016 20:05:51 -0400 Subject: Re: [RFA 02/22] Use RAII to save and restore scalars To: Tom Tromey References: <1474949330-4307-1-git-send-email-tom@tromey.com> <1474949330-4307-3-git-send-email-tom@tromey.com> <20160927085937.com7c7ct4wuchzpg@ball> <87wphtfmcj.fsf@tromey.com> <579b45a0-2393-bda9-a244-cb2f7611635f@redhat.com> <87k2dsg1ul.fsf@tromey.com> <87fuogg0jr.fsf@tromey.com> <01d6497c-7421-d234-e5b3-60a825b43c36@redhat.com> <8760pafzh0.fsf@tromey.com> Cc: Trevor Saunders , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <02ddbb3a-20ec-3cbb-6555-83ca2c5420d4@redhat.com> Date: Wed, 05 Oct 2016 00:06:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <8760pafzh0.fsf@tromey.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00071.txt.bz2 On 10/02/2016 06:11 PM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > >>> However, once you need a copy constructor, it doesn't seem possible >>> without a move constructor. The issue is that a copy constructor take a >>> const reference, so you can't modify the fields of the original. > > Pedro> You can -- make the fields mutable. > > Ok, yeah, I had thought of this, but it seemed pretty ugly to me. It's hidden in the "library", so it'd be super fine with me. I think of it as just part of the idiom. > > Instead I removed all the 2 argument forms in favor of a second explicit > assignment. This solves the problem as well. OK, I thought a little bit more about my worry with the implicit copy constructor, and I think I was originally right -- it doesn't make a difference; things still work if the compiler doesn't elide, because the single-argument form doesn't change the global. Guess you could confirm things still build and run properly with -fno-elide-constructors. > I can go back and do the mutable thing if you really prefer it though. I don't have a strong preference. Maybe client code using the 1-argument form ends up looking cleaner, in any case, not sure. > > > Pedro> The gist is that I think that the features supported by compilers that > Pedro> people are using in practice to build gdb with is what matters > Pedro> in the end, not really C++03 vs C++11. > > The issue I see is that it's just too easy otherwise for C++11isms to > slip in, especially considering that everybody doing development is > likely to be using a compiler with all the C++11 features. Maybe > buildbot can do C++03 builds to check. I still disagree to an extent. Even if we were claiming to require "C++11", we probably wouldn't be able to use _all_ of C++11. E.g. if we wanted to require full C++11 support, then we're need to require gcc 4.8, which was released in 2013. I'd be super fine with requiring it personally, and I look forward to the day, tbc! I think it's present in all current versions of major distros, I believe, I wouldn't be surprised to find opposition, though. As compromise, I think we could be much better at documenting the older gcc version that we actually support compiling with. That oldest-supported version, I think should be decided based on what's the oldest version people really care about, and are willing to routinely test, vs how bad we'd want the C++11 features not supported by that old compiler. Last this was discussed, in context of deciding whether to move forward with the C++ conversion, we settled on gcc 4.2 at least, since that's what some BSDs were still using. But we have nothing in place to enforce that, and I suspect that we still build correctly with older gcc's even. Or not, I don't know, since no one is testing it, for all I know (i.e., no one is sending test reports to gdb-testers@). I think all BSDs have llvm/clang in their base systems now, so those are probably no longer really a concern. Because, if we could require say, gcc 4.3 at least, then we could make use of rvalue references. If we required gcc 4.4, then we could use "auto" and other goodies. Etc. IOW, if we took an incremental approach, we'd be bound by the level of C++11 support in the oldest compiler we supported. https://gcc.gnu.org/projects/cxx-status.html#cxx11 And _that_ version is what I think should be tested by the buildbot, irrespective of C++98/C++03/C++0x/C++11/... instead of being artificially blocked by -std=c++03 or some such. Thanks, Pedro Alves