From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18007 invoked by alias); 14 Oct 2009 20:00:33 -0000 Received: (qmail 17993 invoked by uid 22791); 14 Oct 2009 20:00:31 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.network-theory.co.uk (HELO mail.network-theory.co.uk) (66.199.228.187) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Oct 2009 20:00:27 +0000 Date: Wed, 14 Oct 2009 20:00:00 -0000 Message-ID: From: Brian Gough To: Gerard Jungman Cc: gsl-discuss@sourceware.org Subject: Re: some general questions In-Reply-To: <1254861292.28192.239.camel@manticore.lanl.gov> References: <1254708349.18519.4.camel@ForbiddenPlanet> <7f1eaee30910050750l738876b1p41e6bd8ae5aa6d16@mail.gmail.com> <1254783975.28192.103.camel@manticore.lanl.gov> <87ljjojys0.wl%bjg@network-theory.co.uk> <1254861292.28192.239.camel@manticore.lanl.gov> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.2 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Message-Mac: 1d4b84a1f42983058da7972d487efee3 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: 2009-q4/txt/msg00018.txt.bz2 [Sorry for the delay in replying, I was moving house.] At Tue, 06 Oct 2009 14:34:52 -0600, Gerard Jungman wrote: > Let me see if I understand this. There are two independent > definitions of the GSL_RANGE_COND macro, one which knows > about gsl_check_range, and one which doesn't. GSL header > files with inline function definitions use the version > which does not know about gsl_check_range, through its > definition in gsl_inline.h. C implementation files use > the one which does know about gsl_check_range, through > its definition in build.h. Is this right? Yes, that is correct. > It's confusing to me, but never mind that. What I don't > understand is how you prevent them from colliding in the > presence of both definitions. Obviously I understand > that build.h #undef's it and redefines it. I'm not > asking a mechanical question. I mean to ask, why > do they need to be the same name? We now compile all the non-inline versions of functions directly from their inline definitions in the header files. This avoids any inconsistencies (previously we had separate implementations). GSL_RANGE_COND is redefined in the non-inline version to allow range checking via gsl_check_range so the user can at least manually make it consistent with their choice of whether or not to use range checking in the inline versions. > This is the part I am asking about. I remember when that happened, > and somebody reported it. This was years ago. And I thought we > concluded that such compilers were brain-damaged, but we would > just go ahead and placate them. Q: Are such compilers still > brain-damaged, are they actually doing the right thing (I can't > imagine), or what? I don't have my copy of the standard at the moment. Maybe somebody could look it up. > I think this has bugged me other times as well, though I > couldn't put my finger on what was wrong. I just kept > making clean and rebuilding. Well, does it work better > now? If so, then let's turn it on. Ok, I have just done that. > It's not obvious that they would be unreadable. What I'm asking > is, can you think of some clever way to make them both readable > and generic? Not really. Suppose someone knows (partially) the name of the function or some other part of the prototype and greps the header files for it -- if it is declared via a macro they will not find it. > > A starting point would be to generate a dependency graph using one of > > the automated tools for this - for example, GNU cflow. > > I don't think this is a problem for machine solution. It's up to > us to decide how the thing is organized. What depends on what, > which parts are foundational, and which parts are built on > top of those? Then we should organize the code so it > expresses that. I was just thinking that it's not always obvious what the dependencies are. For example, the special functions depend on linear algebra (through the Mathieu function, which needs to compute some eigenvalues) and there may be some other cases like that.