#1 Improve const correctness

[Markus Elfring]

Would you like to apply the advices from the
article "http://en.wikipedia.org/wiki/Const_correctness"
to your sources?
I suggest to add the key word "const" to the type
specifiers of parameters like the following.
- learner (functions "find_in_learner", "save_learner")
emp (function "find_in_empirical")
buf (function "load_regex")
c (function "good_char")

http://cvs.sourceforge.net/viewcvs.py/dbacl/dbacl/src/db
acl.h?rev=1.1.1.8&view=markup

- sym (function "print_token_delim")

http://cvs.sourceforge.net/viewcvs.py/dbacl/dbacl/src/h
mine.h?rev=1.1.1.2&view=markup

[Laird Breyer]

Logged In: YES
user_id=678360

Thanks for the suggestion. I'm reluctant to add const
correctness at this stage because dbacl's internal function
interfaces are not supposed to be very stable yet, ie not
used as a public API. Also, the code modifies some buffers
transparently behind the scenes and this is harder to do if
an explicit contract is given in function parameters.

Once dbacl's internal functionality is stable, I'll define
an API/library format and the const correctness will make
much more sense.

[Markus Elfring]

Logged In: YES
user_id=572001

I am curious on the design on this API in the (near) future.
(Should this item be left open as an reminder?)

Are the public interfaces const-correct at all places already?

[Laird Breyer]

Logged In: YES
user_id=678360

I'm happy to leave the item open as a reminder and for
others to read and get ideas from. However, I have to
disappoint you about the API, it's not likely to happen very
soon. I'll explain below.

Since you've obviously looked at the source code, you have
seen that the code is modular in some places, but messy and
repeats itself in other places. There are still some global
variables (such as u_options, m_options) but most functions
accept a category_t or learner_t structure, which are the
obvious objects for a future API. The filtering functions
(xml_character_filter and mbox_line_filter) also follow a
modular design with external state objects..So a simple
reentrant API can be defined by creating a state object
which contains all the remaining global variables and
buffers and changing the source references to these globals.

At a lower level, the main buffers are modified in
complicated ways because
of interactions between mmap, fopen, where the code tries to
degrade gracefully, and I don't know if this breaks const
correctness but it probably does. From the point of view of
an API, this is a messy area.

But dbacl's biggest technical problem at the moment is the
amount of memory it uses for learning. This can be reduced
by a lot, but it needs some careful thinking and
experimentation, and it means a big change in the hash table
system, so the functions find_in_learner, save_learner etc.
will change dramatically and I really don't know everything
that will be affected.

So an API is possible, but I would say premature before the
memory problem is solved. Certainly, memory would be an
issue for any program which was using the API, so it must be
addressed sooner or later.