From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21606 invoked by alias); 15 Apr 2008 15:12:19 -0000 Received: (qmail 21584 invoked by uid 22791); 15 Apr 2008 15:12:16 -0000 X-Spam-Check-By: sourceware.org Received: from an-out-0708.google.com (HELO an-out-0708.google.com) (209.85.132.241) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 15 Apr 2008 15:11:59 +0000 Received: by an-out-0708.google.com with SMTP id c23so815524anc.42 for ; Tue, 15 Apr 2008 08:11:57 -0700 (PDT) Received: by 10.100.47.13 with SMTP id u13mr15098511anu.25.1208272316846; Tue, 15 Apr 2008 08:11:56 -0700 (PDT) Received: by 10.100.37.19 with HTTP; Tue, 15 Apr 2008 08:11:56 -0700 (PDT) Message-ID: Date: Tue, 15 Apr 2008 15:12:00 -0000 From: "Hongzheng Wang" To: "Heikki Orsila" Subject: Re: [Help-gsl] GSL and C99 standard Cc: "Brian Gough" , gsl-discuss@sourceware.org, help-gsl@gnu.org In-Reply-To: <20080415105854.GF24451@jolt.modeemi.cs.tut.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <87wsn5irwq.wl%bjg@network-theory.co.uk> <20080411124025.GC24451@jolt.modeemi.cs.tut.fi> <87zlrvh0a1.wl%bjg@network-theory.co.uk> <20080415105854.GF24451@jolt.modeemi.cs.tut.fi> 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 X-SW-Source: 2008-q2/txt/msg00022.txt.bz2 > The benefit of C99 is common conventions that are portable between > projects. The new floating point stuff is probably useful for GSL, but I > see C99 being much more than that. It makes general coding easier. Agree. Basically, I think the problem is not just what benefits we could get when utilizing the new features of C99. More important thing, in my opinion, is that GSL must be ready for these welcome elements introduced by the new standard. Let's still take complex number support as an example. When full C99 support is ready and gets certain applications in the future (some people even argue if this will be true, but I believe it), a user new to GSL may have already a plenty of codes built on the standard complex type support and would feel confused if GSL still uses current non-standard complex number mechanism. Such incompatiblities between GSL and standard would harm the development of GSL and even cause divergence among potential users. -- HZ