From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31485 invoked by alias); 6 Oct 2009 16:21:09 -0000 Received: (qmail 31474 invoked by uid 22791); 6 Oct 2009 16:21:07 -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; Tue, 06 Oct 2009 16:20:58 +0000 Date: Tue, 06 Oct 2009 16:21:00 -0000 Message-ID: <87ljjojys0.wl%bjg@network-theory.co.uk> From: Brian Gough To: Gerard Jungman Cc: gsl-discuss@sourceware.org Subject: Re: some general questions In-Reply-To: <1254783975.28192.103.camel@manticore.lanl.gov> References: <1254708349.18519.4.camel@ForbiddenPlanet> <7f1eaee30910050750l738876b1p41e6bd8ae5aa6d16@mail.gmail.com> <1254783975.28192.103.camel@manticore.lanl.gov> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 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: 783615e337bed9bc6d5a55894e6a873b 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/msg00006.txt.bz2 At Mon, 05 Oct 2009 17:06:15 -0600, Gerard Jungman wrote: > Q1. Regarding header files: Why are the struct declarations inside > __BEGIN__DECLS / __END_DECLS pairs? I think they could be outside. > I have in mind some ideas for better interaction with C++, which > we can discuss later. In any case, if they can go outside (and > I'm pretty sure they can), then they should. There's nothing > "extern C" about a struct declaration. I'm 99% sure you are right. Other than slight inelegance, is there any specific problem with them being inside? Presumably it does not prevent them being used in C++. > Q2. How is the global variable gsl_check_range supposed to work? > It doesn't seem to be used in any way. Is it just cruft? It is used in the non-inline version of the inline functions, so that checking can still be controlled if the compiler uses the static versions of the functions for some reason. See build.h which is included in files defining the static versions of the functions. > Q3. Why do we still have the 'const' qualifiers on by-value parameters > in some header files? I remember it had something to do with the > behaviour of a brain-damaged compiler (microsoft?) ten years ago. > But that was ten years ago. Let's clean that up. What does > the standard say? On some functions we wanted to declare a variable const just for safety in the implementation of the function (this is not strictly necessary of course). The only way to do that is to put const on the argument in the definition -- and there are a number of compilers which complain if it is not on the prototype as well. I believe some compilers do actually handle the case of a const scalar argument more efficiently by keeping it in a register (in fact I think gcc does this now in some cases), so one could argue that we should do that in more cases. > Q4. Why are the dependencies for including "source" files in the > templatized world broken? Updating a "templatized" source > file does not force a recompile; obviously it should. In configure.ac we have AM_INIT_AUTOMAKE([gnu no-dependencies]) We didn't use them originally because they weren't very reliable in old versions of Automake. We could turn them back on now if you want. > Q5. Can we extend the "templatizing" scheme to generate > declarations too? Of course, if it obscures the > header files, then it is not acceptable. The problem would be that it would make them unreadable to the user (they would have to figure out how the macros work to read the prototypes). Also it might hinder any automated tools which look at the headers (e.g. for auto-completion of function names etc). What we could do is adopt a more standardised way of generating the header files, rather than using an undocumented perl script. That would mean using m4 or something like that. > Q6. More a statement than a question: We should be more explicit > about the levelization of the design. This means expressing > the dependence of components clearly. For example, matrix > depends on vector, yet there is nothing in the build or in > the structure of the library which makes this clear. > Everything depends on error handling. Some things depend on > ieee. Some things are almost standing alone. We currently > have no meaningful notion of sub-libraries or component > dependency. A starting point would be to generate a dependency graph using one of the automated tools for this - for example, GNU cflow. > Simple observations, for people who don't get it: > > * There are too many "things" in the root directory, > both files and directories. I have no problem if you want to move some of these into a subdirectory, e.g. examples/ or sys/ etc