bogotune broken? Larger data* revision committed to CVS.

[David Relson]

On Mon, 22 Nov 2004 00:00:50 +0100
Matthias Andree wrote:

...[snip]...

> 
> > Having pure functions is of value.  Putting lots of (formerly)
> > global variables into a structure to purify the functions doesn't
> > seem valuable.  I'd rather see accessor functions defined as inline
> > functions.
> 
> That cannot work in portable C. The variable is in a different
> compilation unit but if you want to inline the accessor function, it
> must be in the same compilation unit as the variable. Hence, variable
> and accessor function must be in the same unit of compilation as the
> user of that variable. But if that's the case, the accessor function
> becomes redundant.
> 
> > At least, grep could then be used to determined whether the
> > variable is being read or modified.
> 
> True.

The following works (although the compiler complains about the externs).
.  It limits knowledge of the variable and gives the appearance of
accessors without any speed penalty.  However, it really isn't very
useful :-<

extern inline int getVal(void){
    extern int value;
    return value;
}

extern inline void setVal(int v)
{
    extern int value;
    value = v;
}

> > > I'm not in favor of accessor functions for static variables, we
> > > aren't gaining anything through them except additional complexity.
> > > We may as well do it right and allocate dynamically.
> > 
> > "right" and "dynamically" would be accurate if we were using an
> > object oriented language with class variables.  As we're not doing
> > that, whatever we have is a compromise -- and I can live with that
> > fact.
> 
> We are effectively emulating OOP through abstraction layers.

Something like that :-)

> > > Presentation is a matter of the editor software. emacs's speedbar
> > > for one. I rarely access functions by scrolling, I usually access
> > > via tags- way faster regardless of where the function is, and the
> > > static declarations confuse the tags generator.
> > 
> > The compiler imposes its own ordering requirements.  For example,
> > that's why main() is usually at the end of a file even though it's
> > the first function to execute.  Including forward declarations
> > allows functions to be ordered as seems most logical or convenient.
> 
> True. We aren't getting anywhere as we have different opinions on
> that, so I'm willing to go whatever we have. I'll need to try what
> happens if I steal emacs the GNU ctags and give it Darren Hiebert's
> Exuberant Ctags instead.

I've been using etags (a little) and haven't noticed problems.  Years
ago, I used to be a big tags user, but have fallen out of the habit..

> > > > The handler was needed to ensure the database gets closed.  If
> > > > that assurance is no longer necessary, it can be dropped.
> > > 
> > > We may rather need to fix the paths out of our software for those
n> > > error conditions that are recoverable and/or do not damage the
> > > database.
> > 
> > atexit() provides a poor man's form of exceptions.  'Tis too bad
> > that proper exception handling requires a language like C++ (which
> > would cost us portability).
> 
> Poor man's exceptions are called setjmp ("try/catch" in one) and
> longjmp("throw") and the sig* variants. They're even ANSI-C which has
> been around for 15 years so there'll be no excuse if some system
> doesn't have these. :-)

I considered them, but shied away...

> > > "make check" doesn't appear to run exit paths that fail to close
> > > the databases, except perhaps t.bulkmode. You'll find out.
> > 
> > I'll tweak bogofilter to let us know when (if) it reaches the exit
> > handler before closing the databases.
> 
> Good idea.

I've got code with a wordlists open/closed flag and a test in bf_exit().
 "make check" indicates bf_exit() isn't needed.

Regards,

David

P.S. I'll add '-x' support to bogotune.  If recollection serves, it only
takes a line or two of code.