From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22390 invoked by alias); 6 Oct 2009 20:32:34 -0000 Received: (qmail 22372 invoked by uid 22791); 6 Oct 2009 20:32:33 -0000 X-SWARE-Spam-Status: No, hits=-10.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: sourceware.org Received: from proofpoint2.lanl.gov (HELO proofpoint2.lanl.gov) (204.121.3.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Oct 2009 20:32:29 +0000 Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103]) by proofpoint2.lanl.gov (8.14.3/8.14.3) with ESMTP id n96KWRDU027213 for ; Tue, 6 Oct 2009 14:32:27 -0600 Received: from alvie-mail.lanl.gov (alvie-mail.lanl.gov [128.165.4.110]) by mailrelay2.lanl.gov (Postfix) with ESMTP id 8817215CA94A for ; Tue, 6 Oct 2009 14:32:27 -0600 (MDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by alvie-mail.lanl.gov (Postfix) with ESMTP id 85D227D00D9 for ; Tue, 6 Oct 2009 14:32:27 -0600 (MDT) X-NIE-2-Virus-Scanner: amavisd-new at alvie-mail.lanl.gov Received: from [130.55.124.157] (manticore.lanl.gov [130.55.124.157]) by alvie-mail.lanl.gov (Postfix) with ESMTP id 6C7917D004F for ; Tue, 6 Oct 2009 14:32:27 -0600 (MDT) Subject: Re: some general questions From: Gerard Jungman To: gsl-discuss@sourceware.org In-Reply-To: <87ljjojys0.wl%bjg@network-theory.co.uk> References: <1254708349.18519.4.camel@ForbiddenPlanet> <7f1eaee30910050750l738876b1p41e6bd8ae5aa6d16@mail.gmail.com> <1254783975.28192.103.camel@manticore.lanl.gov> <87ljjojys0.wl%bjg@network-theory.co.uk> Content-Type: text/plain Date: Tue, 06 Oct 2009 20:32:00 -0000 Message-Id: <1254861292.28192.239.camel@manticore.lanl.gov> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2009-10-06_17:2009-09-29,2009-10-06,2009-10-06 signatures=0 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/msg00009.txt.bz2 On Tue, 2009-10-06 at 17:02 +0100, Brian Gough wrote: > 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++. I am toying with an idea like #ifdef __cplusplus struct thingy { thingy() : x(0), y(0) { } int x; int y; }; #else typedef struct { int x; int y; } thingy; #endif The goal being to insure that thingy's are properly default constructed in the C++ world. But I haven't tested it yet. I'm not even sure it it compiles properly. But you get the idea. > > 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. 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? 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? > > 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 -- Yes, I know. > and there are a number of compilers > which complain if it is not on the prototype as well. 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? > > 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]) Ah. I see. > 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. 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. > > 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). 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? > 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. Speak no further about m4. > > 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. 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.