From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26845 invoked by alias); 28 Jan 2016 09:21:37 -0000 Mailing-List: contact libabigail-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: libabigail-owner@sourceware.org Received: (qmail 26820 invoked by uid 89); 28 Jan 2016 09:21:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=H*r:1001 X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: ms.seketeli.fr From: Dodji Seketeli To: Ben Woodard Cc: Mark Wielaard , libabigail@sourceware.org Subject: Re: [PATCH] Remove defined but not used functions pointed out by GCC6. Organization: Me, myself and I References: <1453805186-28282-1-git-send-email-mjw@redhat.com> Mail-Followup-To: Abigail Project Mailing List X-Operating-System: Red Hat Enterprise Linux Workstation 7.2 X-URL: http://www.seketeli.net/~dodji Date: Fri, 01 Jan 2016 00:00:00 -0000 In-Reply-To: (Ben Woodard's message of "Tue, 26 Jan 2016 13:01:12 -0800") Message-ID: <86k2mu9i04.fsf@seketeli.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2016-q1/txt/msg00064.txt.bz2 Hello, Ben Woodard a =C3=A9crit: > I don=E2=80=99t know if these are the kinds of functions that I would get= rid > of. They don=E2=80=99t look like much but even though they aren=E2=80=99t= being used > now, they are the kinds of data access and type conversion functions > that C++ is known for. I agree with you that these are small and simple getter/conversion functions. The special thing, though, is that they are explicit specializations of a template function, for the decl_base_sptr type. What is used in the code today is the specializations of these functions the the var_decl_sptr type. Note that var_decl_sptr can be seen as deriving from decl_base_sptr. In other words, we use a more specialized version of these template functions. And it appears that the more general specialization is not used. So we might as well just get rid of it, because we already have a more precise tool for the task. If we need it later, it's simple enough to be added again. But I suspect that we'll then add even more specialized versions of it. Thank you for this comment. It's cool to have discussions like this :-) Cheers, --=20 Dodji