From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15193 invoked by alias); 9 Sep 2013 19:25:55 -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 15184 invoked by uid 89); 9 Sep 2013 19:25:54 -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:25:54 +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 P7Rq1m0030eyEos017RrGf; Mon, 09 Sep 2013 20:25:52 +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=z-B7hvRT3RkVvYZ5RcMA:9 a=wPNLvfGTeEIA:10 X-AUTH: gladman+brg:2500 Message-ID: <522E20BE.60002@gladman.plus.com> Date: Mon, 09 Sep 2013 19:25: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> <522E1BB5.9070506@gladman.plus.com> In-Reply-To: <522E1BB5.9070506@gladman.plus.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-q3/txt/msg00005.txt.bz2 On 09/09/2013 20:04, Brian Gladman wrote: > 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. Answering my own question, I could simply use GSL_MAJOR_VERSION Brian