Re: some general questions

[Brian Gough <bjg@gnu.org>]

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