On Mon, 26 Apr 2004 11:48:22 +0200, Leopold Toetsch wrote:
>> After, so I already got the interpreter.str file. I guess VC gets confused
>> with the _CONST_STRING(i, __LINE__) thingy, where __LINE__ doesn't get
>> expanded, and the whole results in _CONST_STRING_ instead of
>> _CONST_STRING_1309, etc.
>
>> Now, here comes the weird stuff: If I ask only for the preprocessed source
>> (add option /E to CFLAGS, then "nmake src\interpreter.obj"), this (from
>> interpreter.c)
>
>> gets expanded to
>> sc = (interpreter)->const_cstring_table[1];
>
> Yep, it should look like that. It's of course strange that during normal
> compile this seems not be expanded like with /E.
>
> We could use an alternate scheme with stringifications. With a small
> drawback that it's unusable, if the string isn't and identifier token.
>
> Above define would then be
>
> #define CONST_STRING__interpreter 1
I just hacked up a simple test.c, which looks like this:
#include "interpreter.str"
int main(int argc, char *argv[]) {
CONST_STRING(interpreter, "_interpreter");
}
and added "#define _CONST_STRING_4 1" to interpreter.str.
"cl test.c" complains rightfully
test.c(4) : error C2065: 'interpreter' : undeclared identifier
test.c(4) : error C2223: left of '->const_cstring_table' must point to
struct/union
I'd say we should keep your alternate scheme in our back pocket, and I'll
try to figure out what exactly VC dislikes. It's gotta be something
between test.c and interpreter.c. ;-)
Ron
