Re: some general questions

[Brian Gough <bjg@gnu.org>]

[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.