From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112615 invoked by alias); 25 Oct 2016 20:29:25 -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 112586 invoked by uid 89); 25 Oct 2016 20:29:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=buried, realization, sand, evil 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; Tue, 25 Oct 2016 20:29:21 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 7BE7161E78 for ; Tue, 25 Oct 2016 20:29:20 +0000 (UTC) Received: from valrhona.uglyboxes.com (ovpn03.gateway.prod.ext.phx2.redhat.com [10.5.9.3]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9PKTJ2Z024205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Oct 2016 16:29:20 -0400 Subject: Re: C++11 (abridged version) To: Pedro Alves , GDB Patches References: <4300d24a-8711-c5de-79ce-7c530162288c@redhat.com> From: Keith Seitz Message-ID: <580FC09F.6010304@redhat.com> Date: Tue, 25 Oct 2016 20:29:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <4300d24a-8711-c5de-79ce-7c530162288c@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00714.txt.bz2 Hi, Pedro, I'm normally a "go with the flow" kind of person, and I've pretty much had my head buried in the compile "sand," but I felt this topic important enough to say something -- even if it has already been said. TL;DR: I'm *all* for moving directly to C++11. I'm already using quite a bit of it on C++ Compile. On 10/20/2016 10:07 AM, Pedro Alves wrote: > A large discussion around that patch followed [1], circling around a > few related points: > > #1 - whether we should be reimplementing C++11 features. > Developers will undoubtedly find future standard library (or boost) concepts, algorithms, etc useful now. Sometimes *very* useful. std::unique_ptr (and I'd argue shared_ptr) is such a case we are seeing today. A requirement to maintain some backward-compatibility (compiler-longevity?) necessarily leads to implementing some of the newer, highly-desirable/beneficial library features ourselves. I don't think this is an uncommon practice. For me this C++11 "now" decision arises from the realization that C++11 is so much more useful that we might as well simply jump straight to using it. It contains a handful of concepts that would be non-trivial or perhaps even impossible to implement outside direct compiler support, e.g., "auto", lambda functions, ... While I'm no C++ guru, I don't think I would be alone in saying that C++11 is the language specification C++ should have had years ago. > #2 - whether we should be taking advantage of C++11 features when > available, provided we have C++03 fully functional fallbacks in > place. (and then generically, $version+1 features provided we > have $version fallbacks.) I'm generally fine with this. Again it seems a "necessary evil." However, there is one concern I have, and the recent unique_ptr patch exemplifies this. We now have a "unique_ptr." In fact, when using a real C++11 compiler, gdb_unique_ptr.h will actually just alias a real C++11 std::unique_ptr to gdb::unique_ptr. Alas, > - Putting gdb::unique_ptr in standard containers is not supported, > since C++03 containers are not move-aware (and our emulation > relies on copy actually moving). The comment above shows that while the two are similarly named, gdb::unique_ptr isn't yet really a real unique_ptr. However, for developers like me who do use a C++11-compliant compiler, that's one hidden gotcha waiting to be discovered. Fortunately, I read the sources and discovered this before I used unique_ptr in containers on the c++compile branch. I'm (mildly) concerned that this could too easily lead to yet-another "our own dialect" of C++(11) scenario(s). Of course, it is *far* too early to make any concrete assertions about this. The code has only been in the repository one week. > #3 - whether we should instead switch to require a C++11 compiler > We gotta start somewhere, and IMO, C++11 is *by far* the best "safe" place to do so. > #4 - if so, then what is the policy to accept the next standard > versions going forward. I don't know how comfortable I am with such black-and-white rules, but I think/hope that maintainers remain *flexible* about decisions like this. Do what is "right" when it is "right." [That's not a "rule," per se, but what I'd like the "spirit" of the rule to be.] I think your offering on this policy indicates that you and I are in agreement. I'm already using C++11 features, and I am absolutely in favor of moving directly to C++11. TL;SW* Keith * Too Long; Stopped Writing :-)