Maximus
February 7th, 2010, 19:16
well,
this is a bit funny... I am working in a project using multiple compilers. So far, nothing strange: every compiler has its own idioms.
It is also well known that MSVC cpp (c preprocessor) is a bit buggy, but...
look to the hack I had to do to compile a piece of code that compiles flawlessy on other compilers:
the fun is, if I generate the ".i" files the cpp correctly expands the macro (so the #conditional block is not needed) but as long as I compile it normally, it complais of those missing closing brackets!!
---
well, that's interesting: now it compiles, but it totally REFUSE to generate the proper code, which it generates if the macro is... not macroed (and there it complais not of the brackets). Bah.
---
well, in the end, it seems that it is due to the fact that the code contains inline __asm statements: probably the compiler isnt capable of expanding assembler AND macro at the same time...
this is a bit funny... I am working in a project using multiple compilers. So far, nothing strange: every compiler has its own idioms.
It is also well known that MSVC cpp (c preprocessor) is a bit buggy, but...
look to the hack I had to do to compile a piece of code that compiles flawlessy on other compilers:
Code:
void func()
{
...
//
MY_CODE_IN_MACRO(...);
#ifdef MS_FIX_BUGGY_CPP_VERY_UGLY_HACK
};
};
};
#endif
...
};
the fun is, if I generate the ".i" files the cpp correctly expands the macro (so the #conditional block is not needed) but as long as I compile it normally, it complais of those missing closing brackets!!
---
well, that's interesting: now it compiles, but it totally REFUSE to generate the proper code, which it generates if the macro is... not macroed (and there it complais not of the brackets). Bah.
---
well, in the end, it seems that it is due to the fact that the code contains inline __asm statements: probably the compiler isnt capable of expanding assembler AND macro at the same time...