From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id RR1TGCahGmEZEgAAWB0awg (envelope-from ) for ; Mon, 16 Aug 2021 13:32:22 -0400 Received: by simark.ca (Postfix, from userid 112) id 533541EDFB; Mon, 16 Aug 2021 13:32:22 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 891BE1E4A3 for ; Mon, 16 Aug 2021 13:32:21 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0DAC73953420 for ; Mon, 16 Aug 2021 17:32:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0DAC73953420 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1629135141; bh=EhycaN2l4ngSFBFU/tp7hLa/ZjOnSSqaktyGbHoQ0CU=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=lwvMnemPvMKQKlMIMgmCEoHTUyWYCFBzxWuHTDJg83n6dirBTNLLw92XO43WYzCw6 DSpqoyGn+1EuXExavmVPsgnAQWyA2kHeDqxCFr7ZPc3JJF55h0opxzEgnAio5jRHKZ 2x6f8aX0hvPCNq/VC1n1PXlxXWIWuNCinfrnHjq8= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 1F10B385840A for ; Mon, 16 Aug 2021 17:31:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1F10B385840A Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 17GHVjU7022607 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Aug 2021 13:31:50 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 17GHVjU7022607 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 8E3A31E4A3; Mon, 16 Aug 2021 13:31:45 -0400 (EDT) Subject: Re: Coding standards proposal, usage of "this" To: Luis Machado , John Baldwin , Simon Marchi via Gdb-patches References: <4bd1cb46-fdcc-cb6a-c7ad-22aba3294772@FreeBSD.org> <00698c41-1af7-b9a8-f127-449a1a06911c@polymtl.ca> <1fd0ea1c-7226-62a0-0568-6793a41ab9a7@linaro.org> Message-ID: <09fc59b5-aa7b-d364-47b3-8d9ba43b4c4f@polymtl.ca> Date: Mon, 16 Aug 2021 13:31:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <1fd0ea1c-7226-62a0-0568-6793a41ab9a7@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 16 Aug 2021 17:31:45 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > My 2 cents. I wouldn't mind the change, but having to remember when to use "this" and when not to use it is worse to me than spending a couple minutes trying to figure out why the code is the way it is. Hmm, I think that when the rule is logical and you know the rationale, it's pretty obvious when to use it or not. In my original proposal: - does the identifier name contains something that makes it obvious it's a member (the m_ prefix)? No need for `this`. - otherwise? Use `this`. > I suppose it is just the nature of C++. Some constructs are just not great when trying to read/parse them. I think the same happens with some templates and lambda's. It might take a little bit to figure out where the functions are defined. > > Given GDB's code base is a mix of C and C++, wouldn't we risk having yet another mix of new coding standards with old coding standards? Yes, but in my opinion we shouldn't refrain of adopting new rules and standards that we find useful because the existing code doesn't follow the new rule. Otherwise we could never introduce any new rule / guideline / standards. Simon