public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Gerard Jungman <jungman@lanl.gov>
To: gsl-discuss@sourceware.org
Subject: some general questions
Date: Mon, 05 Oct 2009 23:04:00 -0000	[thread overview]
Message-ID: <1254783975.28192.103.camel@manticore.lanl.gov> (raw)
In-Reply-To: <7f1eaee30910050750l738876b1p41e6bd8ae5aa6d16@mail.gmail.com>


Mainly directed at Brian...


** Random questions which touch on GSL as a whole.

 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. POD is POD.
     Language lawyers should correct me if I'm wrong. But I don't
     think it has anything to do with languages, so much as the
     assumptions of binary compatibility inherent in linking
     across the C / C++ barrier.

 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?

 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?

 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.

 Q5. Can we extend the "templatizing" scheme to generate
     declarations too? Of course, if it obscures the
     header files, then it is not acceptable.

 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.

     Simple observations, for people who don't get it:

      * There are too many "things" in the root directory,
        both files and directories.

      * There are loose header files in the root directory.
        Their role cannot be drawn from context when they
	are floating in the open sea.

      * There are actual source files
        (gsl-histogram.c, gsl-randist.c, version.c)
        in the root directory. Blechhh.

     Let's clean house.


  parent reply	other threads:[~2009-10-05 23:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-05 10:12 containers tentative design summary Gerard Jungman
2009-10-05 14:50 ` James Bergstra
2009-10-05 23:00   ` Gerard Jungman
2009-10-05 23:45     ` James Bergstra
2009-10-06 19:59       ` Gerard Jungman
     [not found]     ` <645d17210910060537s762d6323pfd2bec8590ad28e9@mail.gmail.com>
2009-10-06 20:02       ` Gerard Jungman
2009-10-23 21:28     ` Brian Gough
2009-10-27 23:06       ` Gerard Jungman
     [not found]         ` <7f1eaee30910271628h70785125m68e47c7a7b5c25b7@mail.gmail.com>
2009-10-27 23:49           ` Gerard Jungman
2009-10-29 18:06         ` Brian Gough
2009-10-29 20:41           ` Gerard Jungman
2009-10-29 21:40             ` James Bergstra
2009-10-30 16:54               ` Brian Gough
2009-10-30 16:54             ` Brian Gough
2009-10-05 23:04   ` Gerard Jungman [this message]
2009-10-06 16:21     ` some general questions Brian Gough
2009-10-06 20:32       ` Gerard Jungman
2009-10-10 14:45         ` Tuomo Keskitalo
2009-10-24 11:16           ` Brian Gough
2009-10-14 20:00         ` Brian Gough
2009-10-15 18:39           ` Tuomo Keskitalo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1254783975.28192.103.camel@manticore.lanl.gov \
    --to=jungman@lanl.gov \
    --cc=gsl-discuss@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).