Re: some general questions

[Gerard Jungman <jungman at lanl dot gov>]

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.