Introduction
For those that are not familiar with the GIM Project yet, you can learn more by reading this thread or on this initial project site. There are basically three main parts to make a GIM module as shown by the following diagram:


gim.h is the controlling thread through which any User Interface should be able to hook up to any data implementation. This thread describes one manner in which the Data Implementation for the contact module can be done.

Data Structure
For this implementation, I have used my custom double-linked list structure. The doubly-linked list works extremely well for this type of use, as long as the data set is relatively small. Even then, the only place that the dl list really falls behind is when the entire data needs to be sorted (probably not noticeable until several thousand entries). This could be solved by writing an improved sort routine when the entire structure needs to be resorted.

Also, this data implementation is a stand-alone version that reads a single file and writes back to that single file when done. This is great for a single user, but does not really lend itself towards shared usage.

One of the rules of gim.h was that the control file itself and all functions that are prototyped therein shall adhere to C calling conventions. Although it is highly unlikely, there may be some pure C implementations of either the user interface or data interface. It makes for a little bit of a challenge in some areas, but with a global variable or two this is quite easy to overcome. Remember, only the function prototypes themselves need to adhere to C. The implementation can use any and all features of C++ as my data implementation does.

Everything is implemented as described by gim.h. This includes custom sorting and filtering capabilites.

Test User Interface
In order to test the data implementation, I have written a console user interface. This is an extremely basic interface, but does allow full functionality of the contact module. There is absolutely no direct contact between this user interface and the data implementation. Therefore, this test user interface can be used with *any* data implementation. In fact that will be a requirement of anyone submitting an alternative data implementation.

The test program uses the classical single letter menu. The following is what this menu looks like:
The current filename is shown in the first line. The '*' means that there is unsaved data. The second line gives the contact name of the current contact. I beleive that the menu items themselves are fairly straight forward. If there is some struggles with the usage, I will write some basic usage instructions.

A couple more things about the test program.

• It is not meant to be elegant. For example I have not trapped for ctrl-c because I want to be able to break this program potentially.
• It is far from error free, but I am really comfortable with the memory management of both the tester program as well as the data implementatin. Why? Because I have used valgrind under linux to check for memory errors and leaks. I was shocked by how many memory gaps my program had prior to using this. This is a great free utility, unfortunately it is only available under linux.
• This should be used as a sample for creating a user interface. In fact if you are creating a user interface it is almost better that you don't look at the data implementation at all. gim.h creates a virtual barrier between the data and the user interface.

Still Needed
This is the Alpha version of this module. It still needs to have more complete error checking built in, such as memory allocation failure traps. Also, like any program, it needs to be torture tested. I need to figure out what sequence of events causes problems. Does everything work as advertised? Is there a glaring ommision? Is speed adequate on slower machines with a decent size data set?

Files
I have attached all of the source files necessary to create the test program. If anyone wants binaries, I will post them to the website shortly. Another advantage to seperating these modules is the conciseness of the resulting code files. The following is a summary of the files and their corresponding sizes:

• gim.h - Controlling header file - size: 450 lines (mostly comments)
• gim.c - String literals needed for gim.h - size: 22 lines
• gct_data.cpp - Data Implementation file - size: 1035 lines (sparsely commented)
• test.cpp - Test Console User Interface - size: 600 lines (sparsely commented)
• dlist.h - Inline Double Linked List - size: 385 lines (liberal comments)

As long as all the files are under the same directory, the compile command is quite easy. For example, under gcc use:

Summary
The rest of this thread will go through some of the detailed implementation aspects of this module. I was interested in getting the full files posted for those interested in testing it out, so I decided to place my summary post first and attach all the source files. Comments, suggestions and even nicely worded criticisms are welcome.

Attached Files

gim_data-1-19-05.zip (18.4 KB, 20 views)

__________________
The best damn Sports Blog period.

I have uploaded a windows binary for those interested as well. I would really like to see any comments on this. It is not a fancy GUI, but it is a complete contact manager program. We will have a GUI shortly, but I really wanted to see some heavy duty crunching of this data implementation.

Download it here

Fishing for comments...

__________________
The best damn Sports Blog period.

I have downloaded the file, don't hold your breath waiting for me to install it!

__________________
J de Silva
Learning Journal | GIDForums™ | GIDNetwork™ | GIDWebhosts™ | GIDSearch™