From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31872 invoked by alias); 9 Sep 2013 19:04:24 -0000 Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org Received: (qmail 31863 invoked by uid 89); 9 Sep 2013 19:04:23 -0000 Received: from avasout05.plus.net (HELO avasout05.plus.net) (84.93.230.250) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Sep 2013 19:04:23 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_20,KHOP_THREADED,RDNS_NONE autolearn=no version=3.3.2 X-HELO: avasout05.plus.net Received: from [192.168.1.22] ([212.159.26.30]) by avasout05 with smtp id P74K1m0020eyEos0174LLY; Mon, 09 Sep 2013 20:04:20 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=ErXr80sA c=1 sm=1 tr=0 a=nO6JWm9Dsne7RoCvRGnC0w==:117 a=nO6JWm9Dsne7RoCvRGnC0w==:17 a=0Bzu9jTXAAAA:8 a=Wtn52_hbDy8A:10 a=KetRowBgfTIA:10 a=ihvODaAuJD4A:10 a=8nJEP1OIZ-IA:10 a=EBOSESyhAAAA:8 a=EuJAgjKP-RcA:10 a=Ol53DbpzkTjhhLM4AQEA:9 a=wPNLvfGTeEIA:10 X-AUTH: gladman+brg:2500 Message-ID: <522E1BB5.9070506@gladman.plus.com> Date: Mon, 09 Sep 2013 19:04:00 -0000 From: Brian Gladman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "gsl-discuss@sourceware.org" Subject: Re: Issue with Mathieu Function Code References: <522231C2.1060908@gladman.plus.com> <522E0A6F.3040400@colorado.edu> In-Reply-To: <522E0A6F.3040400@colorado.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-q3/txt/msg00004.txt.bz2 On 09/09/2013 18:50, Patrick Alken wrote: > This sounds like a good idea, but we need to maintain binary > compatibility in future releases of GSL. It seems we could easily add > functions with _e names, since they are already implemented. But we need > to maintain the old interfaces as well, or at least mark them as > deprecated, so that people can link their programs to the new library > version without needing to recompile. Ah, I hadn't realised that this was an issue. Is there a define somewhere (or could we add one) that would allow those users who are happy to recompile to update to a new interface? What I have in mind is to have --------------------------------- // the new function int function_e(...) { } #ifdef MAINTAIN_BINARY_COMPATIBILITY // keep the old function #define function function_e #else // add the new function double function(...) { EVAL_RESULT(function_e(order, qq, zz, &result)); } #endif This would also make it easy to move to v2.0. I would be happy to do the work involved although it would need checking on Linux. Brian