From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9611 invoked by alias); 3 Feb 2015 16:55:50 -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 9594 invoked by uid 89); 3 Feb 2015 16:55:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 03 Feb 2015 16:55:49 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t13GtiLE004213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 3 Feb 2015 11:55:44 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t13Gtg8a022342; Tue, 3 Feb 2015 11:55:42 -0500 Message-ID: <54D0FD8D.5050408@redhat.com> Date: Tue, 03 Feb 2015 16:55:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCH 4/6] Constify some parameters in the varobj code References: <1422559716-5480-1-git-send-email-simon.marchi@ericsson.com> <1422559716-5480-4-git-send-email-simon.marchi@ericsson.com> In-Reply-To: <1422559716-5480-4-git-send-email-simon.marchi@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-02/txt/msg00053.txt.bz2 On 01/29/2015 08:28 PM, Simon Marchi wrote: > To make it clear that some functions should not modify the variable > object, this patch adds the const qualifier where it makes sense to some > struct varobj * parameters. Most getters should take a const pointer to > guarantee they don't modify the object. > > Unfortunately, I couldn't add it to some callbacks (such as name_of_child). > In the C implementation, they call c_describe_child, which calls > varobj_get_path_expr. varobj_get_path_expr needs to modify the object in > order to cache the computed value. It therefore can't take a const > pointer, and it affects the whole call chain. I suppose that's where you > would use a "mutable" in C++. FYI, in these cases it's totally fine to have the function take a const pointer, and then cast away the const inside the function. We do exactly that in a few places. E.g.: /* Returns the decoded name of GSYMBOL, as for ada_decode, caching it in the language-specific part of GSYMBOL, if it has not been previously computed. Tries to save the decoded name in the same obstack as GSYMBOL, if possible, and otherwise on the heap (so that, in any case, the decoded symbol has a lifetime at least that of GSYMBOL). The GSYMBOL parameter is "mutable" in the C++ sense: logically const, but nevertheless modified to a semantically equivalent form when a decoded name is cached in it. */ const char * ada_decode_symbol (const struct general_symbol_info *arg) { struct general_symbol_info *gsymbol = (struct general_symbol_info *) arg; ... Thanks, Pedro Alves