Re: Initialization of an array and symbolic names for index

Barry Schwarz ha scritto:
This system works well but there is a drawback. When I insert a new record in
How can this work? Your header file declares mys to be a single
struct. Your code in third.c accesses mys as an array. You should be
getting a syntax error.

You are right. In source.h I should declare:
--- source.h ---
....
extern mystruct mys[];
....
---


the middle of the array I should remember to change and re-align the enumeration in the source.h file. Is there a way, maybe using some preprocessor directives, so that I modify/reorder/insert the records only in a point and maintain the coherence in the enumeration?

After you fix the above problem, the answer is still no.

Adding a new element to the array is done by updating source.c and
then compiling it. At this point in time, source.h must exist in
order to be included. Anything you do at this time, such as
preprocessing directives in source.c, will affect only the object file
being generated. Nothing will ever be written back to source.h.
#include is an input operation, not an update one. When you compile
third.c, source.h does not "remember" anything that happened while
compiling source.c.

Ok, I agree with you, but I needn't to have the same structure of files as above. I can use a third file (array.def) to list the names and the values and include it in source.h and source.c, of course with some preprocessing tricks.

I was thinking about the following solution.

--- array.def ---
MACRO( RECORD1, value1 )
MACRO( RECORD2, value2 )
....
MACRO( RECORDn, valuen )
---

--- source.h ---
#undef MACRO
#define MACRO(sym,val) sym,

typedef struct {
int value;
} mystruct;

extern mystruct mys[];

enum MYSTRUCT_INDEX = {
#include "array.def"
};
---

--- source.c ---
#undef MACRO
#define MACRO(sym,val) { val },

mystruct mys[] = {
#include "array.def"
};
---


The above solution works well, but there is a little difference with the first scenario. Here the struct mystruct is composed by only one member. My real struct is composed by several fields.
In this case, I should define MACRO in source.c and source.h in the following way:
--- source.h ---
....
#undef MACRO
#define MACRO(sym, f1, f2, ..., fm) sym,
....
---
--- source.c ---
....
#undef MACRO
#define MACRO(sym, f1, f2, ..., fm) { f1, f2, ..., fm },
....
---

If I change the composition of the struct, I should modify the MACRO definition in source.c and source.h, so I must continue preserving the coeherence of two or three files.
.

Relevant Pages

  • Re: [DRIVER SUBMISSION] DRBD wants to go mainline
    ... * macro, so it is easy do have independend rate limits at different locations ... struct completion startstop; ... this might need a spin_lock member. ...
    (Linux-Kernel)
  • Mixing C and C++
    ... I have therefore implemented the assignment operator to create 'shallow' copy by default (so this is consistent with the C API so that a pointer to the struct could be passed to a C API function with no adverse effect). ... MyStruct(const MyStruct& ms) ... MyStruct& operator= (const MyStruct& rhs) ... void deepcopy ...
    (comp.lang.c)
  • Re: Question about setjmp on Itanium HPUX.
    ... that was the sound of the alignment of your struct ... jmp_buf and your struct. ... The one value which you are guaranteed is safe for struct mystruct is ... Note that in this case, as in your original code, you need to remember ...
    (comp.lang.c)
  • Re: typedefing a struct
    ... typedef struct mystruct { ... typedef struct mystruct mystruct; ...
    (comp.lang.c)
  • Re: #define ALLOCIT(Type) ((Type*) malloc (sizeof (Type)))
    ... returning void* can "beat you". ... to use above macro than raw malloc. ... struct Child; ... inherited from the father of the father of the father of ...
    (comp.lang.c)