From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110177 invoked by alias); 30 Nov 2016 22:58:00 -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 110158 invoked by uid 89); 30 Nov 2016 22:58:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=hurry, sk:table_b, ui_out_impl_* 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 ESMTP; Wed, 30 Nov 2016 22:57:58 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B30C712657; Wed, 30 Nov 2016 22:57:57 +0000 (UTC) Received: from [127.0.0.1] (ovpn03.gateway.prod.ext.phx2.redhat.com [10.5.9.3]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAUMvuxq001471; Wed, 30 Nov 2016 17:57:57 -0500 Subject: Re: [PATCH 19/22] Class-ify ui_out_impl To: Simon Marchi References: <20161124152428.24725-1-simon.marchi@polymtl.ca> <1480173587-7053-19-git-send-email-simon.marchi@polymtl.ca> <8ca5a7eb3f6adac16c8db785bd9fa6d3@polymtl.ca> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Wed, 30 Nov 2016 22:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <8ca5a7eb3f6adac16c8db785bd9fa6d3@polymtl.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg01032.txt.bz2 On 11/30/2016 10:38 PM, Simon Marchi wrote: > I'll consider working on merging ui_out and ui_out_impl_* in a single > class hierarchy. My first question is: what is a good pattern for the > overlapping methods. For example, table_begin. We'll want to execute > the version of the base class, which will then call the specialization. > So we can't use the same name for both. So, keep table_begin for the > base class, and table_begin_impl for the derived classes? Yes. I think gold's convention is to use $method for public methods, and do_$method for protected virtual methods that implementations override/provide. I've seen "do_" used for the same purpose in other projects too. (IIRC, gold is even stricter and requires that virtual methods must be protected, thus mandating that design everywhere. Grep for "this->do_".) >> I'd like to post the gnulib namespace patch this week, >> but I'm not sure I'll be able to. > > And I guess it happens to work anyway for me because both the > declaration, definition and usages get replaced? Yeah, unistd.h is included in defs.h, so it most probably won't be an issue in practice. > > Should I wait for your patch to get in (I'm not particularly in a > hurry), or we can get it in despite "close" getting replaced? Given the above, no need to wait. Thanks, Pedro Alves