Is it OK to #include .c source file for maintainability of embedded C code?

Question

I am not an expert C programmer and I know that including .c source file from another is considered bad practice, but I have a situation where I think it could help maintainability.

I have a big structure with a lot of elements and I use #define to keep the indexes.

#define TOTO_IND 0 
#define TITI_IND 1 
…
#define TATA_IND 50

static const MyElements elems [] = {
    {"TOTO", 18, "French"},
    {"TITI", 27, "English"},
    ...,
    {"TATA", 45, "Spanish"}
}

Since I need to access the structure from index, I need to keep the #define and the structure declaration synchronized. That means that I must insert new elements at the right place and update the #define accordingly.

It is error prone and I don’t really like it (but for performance consideration, I didn’t find a better solution).

Anyway, this file also contains a lot of functions to handle this structure. I also want to keep separation of code and avoid global variables.

To make things “easier”, I was thinking about moving this “error prone definition” to a single .c source file which would only contain this structure. This file would be “the dangerous be careful file” and include it in my actual “normal functional” file.

What do you think about it? Is it a valid situation for including .c source file? Is there another better way of handling my structure?

Answer 1

You could use designated initializers to initialize the elements of elems[] without having to know the explicit value of each index identifier (or macro).

const MyElements elems[] = {
    [TOTO_IND] = {"TOTO", 18, "French"},
    [TITI_IND] = {"TITI", 27, "English"},
    [TATA_IND] = {"TATA", 45, "Spanish"},
};

The array elements will be initialized the same way, even if you change the order they appear in the source code:

const MyElements elems[] = {
    [TITI_IND] = {"TITI", 27, "English"},
    [TATA_IND] = {"TATA", 45, "Spanish"},
    [TOTO_IND] = {"TOTO", 18, "French"},
};

If the array length is set automatically from the initializer as above (i.e. by using [] rather than [NUM_ELEMS]), then the length will be the one more than the maximum element index.

This allows you to keep the index values and external declaration of the elems array in a .h file, and define the elems array contents in a separate .c file.

Answer 2

You should use designated initializers as shown in the answer by Ian Abbot.

Additionally, if the array indices are adjacent as seems to be the case here, you can use an enum instead:

toto.h

typedef enum
{
  TOTO_IND,
  TITI_IND,
  ...
  TATA_IND,
  TOTO_N    // this is not a data item but the number of items in the enum
} toto_t;

toto.c

const MyElements elems [] = {
  [TITI_IND] = {"TITI", 27, "English"},
  [TATA_IND] = {"TATA", 45, "Spanish"},
  [TOTO_IND] = {"TOTO", 18, "French"},
};

And now you can verify the data integrity of the array as whole with a static assert:

_Static_assert(sizeof elems/sizeof *elems == TOTO_N, 
               "Mismatch between toto_t and elems is causing rain in Africa");

_Static_assert(sizeof elems/sizeof *elems == TOTO_N, ERR_MSG);

where ERR_MSG is defined as

#define STR(x) STR2(x)
#define STR2(x) #x
#define ERR_MSG "Mismatching toto_t. Holding on line " STR(__LINE__)

Answer 3

Other answers have already covered it in a clearer way, but for completeness sake, here is an x-macros approach, if you are willing to go down this route and risk your coworker's rage.

X-macros are a form of code generation, using the built-in C preprocessor. The goal is to reduce repetition to a minimum, although with some drawbacks:

1. Source file which generates enums and structures using the preprocessor might seem complex if you are not used to them.
2. Compared to an external build script which would generate the source files, with x-macros you never get to see how the generated code looks like during compilation, unless you use a compiler setting and check for the preprocessed file manually.
3. Since you don't see the preprocessed output, you cannot use the debugger to step through the generated code in the same way you would do with code generated by an external script.

You start by creating a list of macro invocations in a separate file, e.g. elements.inc, without defining what the macro actually does at this point:

// elements.inc

// each row passes a set of parameters to the macro,
// although at this point we haven't defined what the
// macro will output

XMACRO(TOTO, 18, French)
XMACRO(TITI, 27, English)
XMACRO(TATA, 45, Spanish)

And then you define the macro every time you need to include this list, so that each invocation gets rendered into a single row of the construct you want to create -- and you usually repeat this several times in a row, i.e.

// concatenate id with "_IND" to create enums, ignore code and description
// (notice how you don't need to use all parameters each time)
// e.g. XMACRO(TOTO, 18, French) => TOTO_IND,
#define XMACRO(id, code, description) id ## _IND,
typedef enum
{
#    include "elements.inc"
     ELEMENTS_COUNT
}
Elements;
#undef XMACRO

// create struct entries
// e.g. XMACRO(TOTO, 18, French) => [TOTO_IND] = { "TOTO", 18, "French" },
#define XMACRO(id, code, description) [id ## _IND] = { #id, code, #description },
const MyElements elems[] = {
{
#    include "elements.inc"
};
#undef XMACRO

Which will get preprocessed into something like:

typedef enum
{
    TOTO_IND,
    TITI_IND,
    TATA_IND,
    ELEMENTS_COUNT
}
Elements;

const MyElements elems[] = {
{
    [TOTO_IND] = { "TOTO", 18, "French" },
    [TITI_IND] = { "TITI", 27, "English" },
    [TATA_IND] = { "TATA", 45, "Spanish" },
};

Obviously, frequent maintenance of the list becomes easier, at the expense of the generating code becoming more convoluted.

Answer 4

Defining the const as static in multiple files is not a good idea because it creates multiple instances of the large variable MyElements. This will increase memory in an embedded system. The static qualifier needs to be removed.

Here is a suggested solution:

in file.h

#define TOTO_IND 0 
#define TITI_IND 1 
…
#define TATA_IND 50
#define MAX_ELEMS 51

extern const MyElements elems[MAX_ELEMS];

in file.c

#include "file.h"
const MyElements elems [MAX_ELEMS] = {
    {"TOTO", 18, "French"},
    {"TITI", 27, "English"},
    ...,
    {"TATA", 45, "Spanish"}
}

After modification, place #include "file.h" in the required .c files.

Answer 5

To address the specific question about using #include with a .c file (the other answers suggest better options, especially the one by Groo), there is generally no need.

Everything in a .c file can be made externally visible and accessible, so you can reference it via function prototypes and #extern. So for example you could reference your table with #extern const MyElements elems []; in your main .c file.

Alternatively, you could put the definitions in a .h file and include that. That allows you to segregate the code as you want to. Keep in mind that all #include does is insert the contents of the included file where the #include statement is, so it's doesn't have to have any particular file extension. .h is used by convention and most IDEs will automatically add .c files to the list of files to be compiled, but as far as the compiler is concerned the naming is arbitrary.