Thread: avoiding globals

.ini file + getvalue("field")

Originally Posted by joed

I have a program that uses a large number of global variables to store various settings. I've eliminated some by making them static withing their functions, if they aren't used anywhere else.

What is the best way to store lots of settings in a useable way? I would actually like to learn how to eliminate all globals, even if it's somewhat impractical.

It's a design issue.

Globals have two problems:

- They have an external linkage that make them accessible in read and write by anyone.

- They have a permanent duration associated to a uniqueness of instance that makes the code sensible to the 'no-reentrant' problem.

The 'static inside a function' trick can help to solve the first issue, and is sometimes useful.

The only way to solve both issues is to use code that is independent from the data definition. The actual data are defined statically or dynamically by the user, and only the addresses of them are passed to the functions (actually a pointer to an anonymous or not structure). This is Object Oriented Coding, rather than the more classical (at least in C) Function Oriented Coding.

Time to read more about Abstract Data Types (ADT). See how the standard FILE data type and its functions are organized. This is the idea.

Like in C++, you could use singletons, but I don't think there are too many benefits to attemting to mimic this bahavior in C. An example of using global data, as I said above, is as follows.

You can have lots of fun with the above, assuming I'm interpreting your post correctly. I did this recently while writing a task scheduler for a project that will probably never get done, which uses the same concept:

Code:

static TaskList *TaskHandler( TaskInstance **t, Task_h command )
{
    static TaskList *tasks[ TaskB_MaxSlices ]; /* The tasks. */

    ...

    switch( command )
    {
        case TaskH_Enqueue:
        {
            /* These are purposefully hidden functions. */
            static int TaskEnqueue( TaskList *x[], TaskInstance *t );
            TaskEnqueue( tasks, *t );
        }
        break;

    ...
}

/* Comment for board readers: This is in effect the 'interface'. */
int TaskSchedule( TaskInstance *t )
{
    TaskHandler( &t, TaskH_Enqueue );
    return 0;
}

/* Comment for board readers: This would be considered 'implementation'. */
static int TaskEnqueue( TaskList *tasks[], TaskInstance *t )
{
    TaskList **slice = NULL;
    ...

Basicly, the header file for the above only shows how to schedule a task,
complete a task, and cleanup. The rest isn't listed, because the user doesn't
need to know about them. They're purposefully not prototyped, except for in
the handler function, and they're defined after said handler. The actual data
for the table is static inside the hander, and the only way to do anything with
that data, is by using the interface provided to you.

Everything is contained in the handler function. There is no other way to get
at it. At least that's the idea behind it. The reason for the arguments to the
handler, and the return value from it, are so I can:
a) update a pointer if I need to.
b) return a task if I need to.
c) use the return value for error state.

Anyway, that's more than what you're interested in, and is probably off topic
now, but it's rather fun. I'm actually probably going to end up modifying the
handler so it can handle additional task sets, but that's neither here nor there.

Quzah.

I don't know Quzah. TaskHandler looks a lot like message based programming, where by one function dispatches a command. You could even have the dispatch function return a function pointer when given the command. Since access is only through one dispatch function, any of the static data need not be duplicated, almost like the singleton pattern.

But what I was think of was something more of the line of

Code:

typedef struct Singleton {
       int data;
} Singleton;

Singleton* get_singleton_instance();

/** .c file **/
static Singleton* singleton;      

Singleton* get_singleton_instance() 
{ 
       /* or static Singleton* singleton = 0 */
       if (singleton == NULL) {
              singleton =  malloc(sizeof Singleton);
              singleton->data = 5;
       }

       return singleton;
}

As you can see, this solves some of the initialization problems, provided all accesses of singleton are done through get_singleton_instance, which they will be if singleton is a static variable. Although there is a difference in naming and the there is a possibility of the creation other Singleton variables, the result is almost the same if discipline is used. Of course, it's all sort of self-defeating: C programmers are supposed to be used to these type of initialization problems.