From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40864 invoked by alias); 8 May 2019 18:00:44 -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 38912 invoked by uid 89); 8 May 2019 18:00:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:819 X-HELO: gateway24.websitewelcome.com Received: from gateway24.websitewelcome.com (HELO gateway24.websitewelcome.com) (192.185.51.209) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 May 2019 18:00:34 +0000 Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway24.websitewelcome.com (Postfix) with ESMTP id A14ABDC01 for ; Wed, 8 May 2019 13:00:33 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id OQrphqvwm2qH7OQrph8bZH; Wed, 08 May 2019 13:00:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=nwhUELgMLgI4WBAph4zqdscvqOQk6edZMBkB58Ke0iU=; b=ZIYYUqER1Qi1wVTdmdzecZ8/zB bdn7Gl8hdqtjVNU3Fboid5ShXf2pKRzg7f4zibq34hMPaW1r+6+cwfhSD96PkHKKkyRvW7D+4Kuw2 H87rIMbgRNVsm0nVd8XXbmEaA; Received: from 97-122-168-123.hlrn.qwest.net ([97.122.168.123]:48698 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hOQrp-00440l-Da; Wed, 08 May 2019 13:00:33 -0500 From: Tom Tromey To: Simon Marchi Cc: Jan Vrany , Tom Tromey , gdb-patches Subject: Re: [RFC 8/8] mi/python: Allow redefinition of python MI commands References: <20190418152337.6376-1-jan.vrany@fit.cvut.cz> <20190418152337.6376-9-jan.vrany@fit.cvut.cz> <87h8al7tke.fsf@tromey.com> <87woj3mfbs.fsf@tromey.com> <31326cf9e4f843bef7141860306b20ee016b06bf.camel@fit.cvut.cz> <6c3908c7-f4a1-3748-594d-576c68fc42b0@simark.ca> Date: Wed, 08 May 2019 18:00:00 -0000 In-Reply-To: <6c3908c7-f4a1-3748-594d-576c68fc42b0@simark.ca> (Simon Marchi's message of "Tue, 7 May 2019 20:10:39 -0400") Message-ID: <874l64j073.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-05/txt/msg00209.txt.bz2 >>>>> "Simon" == Simon Marchi writes: >>> If we know that we don't access that pointer after it is possibly stale, and >>> we document that fact properly, I think we can keep what you had initially. >>> Using shared_ptr has a cost, and it's not really essential here. >>> >> >> All right. Thanks! Simon> Well that's my opinion, let's see what Tom thinks about it. I'm of two minds. On the one hand, this sort of approach is fragile. It's susceptible to introducing bugs in the future. On the other hand, it seems somewhat unlikely to actually be a cause of bugs, since it's doubtful that more code will be added here. I tend to suspect that using shared_ptr here is not too expensive, but I don't mind either way I guess. Tom