From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14782 invoked by alias); 22 Sep 2016 17:51:19 -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 14718 invoked by uid 89); 22 Sep 2016 17:51:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*r:4.86_1, cleanups, H*F:U*tom, converted X-HELO: gproxy8-pub.mail.unifiedlayer.com Received: from gproxy8-pub.mail.unifiedlayer.com (HELO gproxy8-pub.mail.unifiedlayer.com) (67.222.33.93) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with SMTP; Thu, 22 Sep 2016 17:51:09 +0000 Received: (qmail 22739 invoked by uid 0); 22 Sep 2016 17:51:06 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy8.mail.unifiedlayer.com with SMTP; 22 Sep 2016 17:51:06 -0000 Received: from box522.bluehost.com ([74.220.219.122]) by cmgw3 with id mhr01t00p2f2jeq01hr3Vx; Thu, 22 Sep 2016 11:51:06 -0600 X-Authority-Analysis: v=2.1 cv=aaryw3Yt c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=GW1xBdLrtEIA:10 a=lW1ZodLThXHYGMLH3ZMA:9 Received: from 174-16-151-161.hlrn.qwest.net ([174.16.151.161]:51340 helo=bapiya.Home) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1bn89E-0001Dg-8z for gdb-patches@sourceware.org; Thu, 22 Sep 2016 11:51:00 -0600 From: Tom Tromey To: gdb-patches@sourceware.org Subject: [RFA 0/5] Some random C++-ification Date: Thu, 22 Sep 2016 17:51:00 -0000 Message-Id: <1474566656-15389-1-git-send-email-tom@tromey.com> X-BWhitelist: no X-Exim-ID: 1bn89E-0001Dg-8z X-Source-Sender: 174-16-151-161.hlrn.qwest.net (bapiya.Home) [174.16.151.161]:51340 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-SW-Source: 2016-09/txt/msg00288.txt.bz2 I was feeling inspired by Pedro's Cauldron slides, so I found a few random spots that could be converted from cleanups to self-managing data structures from libstdc++ -- in these cases, std::string and std::vector. I saw a note in one of the C++ conversion documents about perhaps not using std::vector, since GCC did not. However, I think often GCC's uses are unusual, and I don't think there is any reason to avoid std::vector in (most of) gdb. This should probably not go in until after Pedro's "new" patch. Built and regtested on x86-64 Fedora 24. A few reflections on these changes: * First, I think it's a nice improvement. The examples here aren't so dramatic, but if you dig a bit it's easy to find cases where the cleanup logic is complicated; and this approach eventually lets one delegate all that work to the compiler. * Speaking of, I have a patch to convert uses of the ensure_python_env to use RAII. However, I don't think this is ready to go in -- because the cleanups installed by this are order-sensitive with respect to other cleanups that might be created in the various Python-calling functions. My belief is that cleanups have to all be run before any destructors, so any ordering issues are a subtlety that, in the short term, will have to be accounted for in code review. * It wasn't actually clear to me that this kind of change is desirable. * I was unclear on the coding style to use so I just used the gdb C style. Maybe there are some spaces that shouldn't be there now. Tom