How can I maintain correlation between structure definitions and their construction / destruction code?

Question

When developing and maintaining code, I add a new member to a structure and sometimes forget to add the code to initialize or free it which may later result in a memory leak, an ineffective assertion, or run-time memory corruption.

I try to maintain symmetry in the code where things of the same type are structured and named in a similar manner, which works for matching Construct() and Deconstruct() code but because structures are defined in separate files I can't seem to align their definitions with the functions.

Question: is there a way through coding to make myself more aware that I (or someone else) has changed a structure and functions need updating?

Efforts:

The simple:

-Have improved code organization to help minimize the problem

-Have worked to get into the habit of updating everything at once

-Have used comments to document struct members, but this just means results in duplication

-Do use IDE's auto-suggest to take a look and compare suggested entries to implemented code, but this doesn't detect changes.

I had thought that maybe structure definitions could appear multiple times as long as they were identical, but that doesn't compile. I believe duplicate structure names can appear as long as they do not share visibility.

The most effective thing I've come up with is to use a compile time assertion:

static_assert(sizeof(struct Foobar) == 128, "Foobar structure size changed, reevaluate construct and destroy functions");

It's pretty good, definitely good enough. I don't mind updating the constant when modifying the struct. Unfortunately compile time assertions are very platform (compiler) and C Standard dependent, and I'm trying to maintain the backwards compatibility and cross platform compatibility of my code.

This is a good link regarding C Compile Time Assertions:

http://www.pixelbeat.org/programming/gcc/static_assert.html

Edit:

I just had a thought; although a structure definition can't easily be relocated to a source file (unless it does not need to be shared with other source files), I believe a function can actually be relocated to a header file by inlining it.

That seems like a hacked way to make the language serve my unintended purpose, which is not what I want. I want to be professional. If the professional practice is not to approach this code-maintainability issue this way, then that is the answer.

Answer 1

I've been programming in C for almost 40 years, and I don't know of a good solution to this problem.

In some circles it's popular to use a set of carefully-contrived macro definitions so that you can write the structure once, not as a direct C struct declaration but as a sequence of these macros and then, by defining the macro differently and re-expanding, turn your "definition" into either a declaration or a definition or an initialization. Personally, I feel that these techniques are too obfuscatory and are more trouble than they're worth, but they can be used to decent effect.

Otherwise, the only solution -- though it's not what you're looking for -- is "Be careful."

In an ideal project (although I realize full well there's no such thing) you can define your data structures first, and then spend the rest of your time writing and debugging the code that uses them. If you never have occasion to add fields to structs, then obviously you won't have this problem. (I'm sorry if this sounds like a facetious or unhelpful comment, but I think it's part of the reason that I, just as @CoffeeTableEspresso mentioned in a comment, tend not to have too many problems like this in practice.)

It's perhaps worth noting that C++ has more or less the same problem. My biggest wishlist feature in C++ was always that it would be possible to initialize class members in the class declaration. (Actually, I think I've heard that a recent revision to the C++ standard does allow this -- in which case another not-necessarily-helpful answer to your question is "Use C++ instead".)

Answer 2

C doesn't let you have benign struct redefinitions but it does let you have benign macro redefinitions.

So as long as you

1. save the struct body in a macro (according to a fixed naming convention)
2. redefine the macro at the point of your constructor

you will get a warning if the struct body changes and you haven't updated the corresponding constructor.

Example:

header.h:

#define MC_foo_bod  \
    int x; \
    double y; \
    void *p
struct foo{ MC_foo_bod; };

foo__init.c

#include "header.h"

#ifdef MC_foo_bod
    //try for a silent redefinition
    //if it wasn't silent, the macro changed and so should this code
    #define MC_foo_bod  \
        int x; \
        double y; \
        void *p
#else
    #error "" 
    //oops--not a redefinition
    //perhaps a typo in the macro name or a failure to include the header?
#endif
void foo__init(struct foo*X)
{
    //...
}