From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2435 invoked by alias); 17 Nov 2014 17:45:36 -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 2420 invoked by uid 89); 17 Nov 2014 17:45:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 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; Mon, 17 Nov 2014 17:45:34 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAHHjV4g013166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 17 Nov 2014 12:45:31 -0500 Received: from localhost (dhcp-10-15-16-169.yyz.redhat.com [10.15.16.169]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAHHjU2Q015887 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Mon, 17 Nov 2014 12:45:30 -0500 From: Sergio Durigan Junior To: Pedro Alves Cc: "Jose E. Marchesi" , gdb-patches@sourceware.org Subject: Re: [PATCH V3 1/9] Adapt `info probes' to support printing probes of different types. References: <1414504218-31204-1-git-send-email-jose.marchesi@oracle.com> <1414504218-31204-2-git-send-email-jose.marchesi@oracle.com> <87oass6pbc.fsf@redhat.com> <5465F7A5.8040207@redhat.com> <87lhnd754a.fsf@redhat.com> <546A23F8.2030007@redhat.com> X-URL: http://blog.sergiodj.net Date: Mon, 17 Nov 2014 17:45:00 -0000 In-Reply-To: <546A23F8.2030007@redhat.com> (Pedro Alves's message of "Mon, 17 Nov 2014 16:36:08 +0000") Message-ID: <87k32t67ra.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00407.txt.bz2 On Monday, November 17 2014, Pedro Alves wrote: > On 11/14/2014 11:08 PM, Sergio Durigan Junior wrote: >> On Friday, November 14 2014, Pedro Alves wrote: >> >>> On 10/31/2014 06:56 PM, Sergio Durigan Junior wrote: >>>> Also, any particular reason why you did not create a field "type" inside >>>> "struct probe", instead of making a function that returns the string? I >>>> consider the field would be simpler (i.e., not pollute the probe_ops >>>> structure), and it could be set when creating the probes. >>> >>> Not sure I understood it (and probably doesn't matter much), seems like >>> that'd waste memory storing the same info over and over? >> >> We would be wasting sizeof (char *) for each probe created, indeed, but >> I think this is clearer (also for debugging purposes) than having all >> the necessary machinery to call a function that will return the same >> info... > > IMO, that's not cleaner, because the type name is a property of > the type, not of the instance, so it makes sense to get it from the > type (thus through an ops method). Writing the equivalent C++ may > make it clearer. Something like: Fair enough, looking from this perspective I am convinced. > struct probe > { > ... > virtual const char *type_name () = 0; > }; > > struct stap_probe : public probe > { > ... > virtual const char *type_name () { return "stap"; } > }; > > struct dtrace_probe : public probe > { > ... > virtual const char *type_name () { return "dtrace"; } > }; > > > And then in info_probes_for_ops: > > const char *probe_type = probe->probe->type_name (); > >> >> Anyway, I won't oppose the current approach too, I was just curious :-P. > > > Thanks, > Pedro Alves -- Sergio GPG key ID: 0x65FC5E36 Please send encrypted e-mail if possible http://sergiodj.net/