Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Hollywood MAL AMIStore App Store A600 Memory

AuthorTopic: Varargs macros...  (Read 732 times)

0 Members and 1 Guest are viewing this topic.

Offline Jose

Varargs macros...
« on: February 02, 2007, 12:21:13 AM »
You guessed it, another C question from me wich has no solution (last one actually had...), anyway here's the deal:
I wanted to put up a way/macro to record structure's element's  offsets from the structures beggining (so 1st would have 0 offset). All this WITHOUT having to repeat the structure variable the elements belong to. I started using macros but it doesn't seem possible. Example:
Code: [Select]

/* x- structure, y- element */
#define DEF(x, y) ((char *)&x.y) - (char *)&x

or
Code: [Select]

/* x- structure, y- element */
#define DEF(x, y) offsetof(x, y)


could both work (haven't actually tested it) but it's not enouph because you can't define a var args macro :-)
Like:
Code: [Select]

#define DEF(x, y, ...) offsetof(x, y)

wich is of course now allowed.

 A macro definition inside a macro also doesn't work. Neither does using an already predefined macro accepting arguments from another a macro's definition, for example:
Code: [Select]

/* Gets z element's offset from structure x
(x is a an argument for the DEF macro, used with this one) */
#define EL(z) offsetof(x, z),

/* Makes an NULL terminated array of LONGs with the wanted offsets, naming it the name passed in x plus _DEF suffix
(x_DEF).
x- structure, y- offsets that get specified with EL macro
*/
#define DEF(x, y) LONG x##_DEF[] = {y 0}

/* So say we have this struct */
struct SomeStruct
{int a;
 long int b;
  ....
}SmSt;
/* Now we could make definitions for the elements we want like this */
DEF(SmSt, EL(a) EL(b));


Cool ught ? I've made something like this (might have introduced some additional bugs on this one..) and it doesn'r work, complaining that it can't find x or that x is undefined or something.

I've reached the conclusion that this doesn't work beacuse the preprocessor only does one pass, hence not resolving x.

Using the 1st macros repeatedly would probably do it, but that would defeat my initial purpose of only repeating the structure once and then just provide it's elements for the stuff to be done automatically...

@Karlos
Yeah, I know, C++ is better... :-D Really, but I just wanted to manage this one in C for now to finish my small "GeneralSaver" project.. wich has a bunch of code already writen but depends on what  actuall info it receives (and how it's organized) too, so this must be done before finishing it.

Any ideas or thoughts ? :-)
\\"We made Amiga, they {bleep}ed it up\\"
 

Offline Jose

Re: Varargs macros...
« Reply #1 on: February 02, 2007, 04:02:58 PM »
I must tell you that I didn't really knew varargs macros existed in C. I was checking VBCC docs to see what pragmas it has that could help (then I'd do the same for sas and gcc dohh...) when I stumbled in the very name "varargs macros" :-o WTF. So it turns out that these were actually introduced with the C99 spec. (My C book is from before that)...

COoll ught ? :-D

:pint: :pint:
\\"We made Amiga, they {bleep}ed it up\\"
 

Offline Karlos

Re: Varargs macros...
« Reply #2 on: February 02, 2007, 08:08:10 PM »
Regarding the problems you are having with the macros, you have to remember, the preprocessor has absolutely no knowledge of C; it will happily expand macros that generate totally meaningless code for the compiler to complain about.

That said, I've never encountered problems* using function-like macros within other function-like macros, provided they are #defined in the proper order.

*except for the obvious "hmm, that didn't quite expand as intended" bugs that required me to go back in and fix them.

No lectures about C++ this time. I'm sure you'll know better for your next project ;-)
int p; // A