c-preprocessor

I have a general macro: #define mSwitch( Root, Case ) Root##_Case_##Case #define mSpecialDisplay( what, Val ) mSwitch(mSpecialDisplay,what)(Val) #define mSpecialDisplay_Case_Int(Val) ...do stuff #define mSpecialDisplay_Case_Float(Val) ...do stuff ...more special cases how do I guarantee that the variable Case is fully expanded before it gets pasted in mSwitch ? It works fine if mSwitch is passed a literal value, but if there are several layers of indirection, or intermediary operations, mSwitch ends up pasting one of those before they get fully expanded. I'm using MSVC 2005 . Is there a simple

In C++, can I have a defaulted argument to a function which defaults to __PRETTY_FUNCTION___ , ___FILE___ , and ___LINE__ as defined at the point of the caller and not the point the defaults are supplied in a header file without using macros? You can't, but you can acheive this behavior with an additional macro. For instance: #DEFINE THROW(e) throwException(e, __FILE__, __LINE__); On a side note, __PRETTY_FUNCTION__ is not standard. No. Macros are expanded at the source line where they occur. You probably can... but definitely not with the restriction you mentioned (no macros). 来源： https:/

Is there a way to use gcc's -I command and add all the paths to search path by giving a root directory? I'm trying to use :!gcc -E myfile.c to view macro expansions, but myfile.c includes a whole bunch of other header files in different directories, and because I'm executing this command in vim, so I don't want to call a makefile, is there anyway to do this? If you are using Apple's GCC (or Clang), then you can use the following approach (which appears to be an extension): the parameter's suffix will need /** -IMON_DIRECTORY/** Now everything under MON_DIRECTORY/ may be searched. Obviously,

How would I create a C macro to get the integer value of a string? The specific use-case is following on from a question here . I want to change code like this: enum insn { sysenter = (uint64_t)'r' << 56 | (uint64_t)'e' << 48 | (uint64_t)'t' << 40 | (uint64_t)'n' << 32 | (uint64_t)'e' << 24 | (uint64_t)'s' << 16 | (uint64_t)'y' << 8 | (uint64_t)'s', mov = (uint64_t)'v' << 16 | (uint64_t)'o' << 8 | (uint64_t)'m' }; To this: enum insn { sysenter = INSN_TO_ENUM("sysenter"), mov = INSN_TO_ENUM("mov") }; Where INSN_TO_ENUM expands to the same code. The performance would be the same, but the

Given #define cat(x,y) x##y The call cat(a,1) returns a1 , but cat(cat(1,2),3) is undefined. However if I also define #define xcat(x,y) cat(x,y) , then the result of xcat(xcat(1,2),3) is now 123 . Can anybody please explain in detail why this is so? Jay Sullivan I tested this using both GCC and Clang. GCC gives the error: test.c:6:1: error: pasting ")" and "3" does not give a valid preprocessing token Clang gives the error: test.c:6:11: error: pasting formed ')3', an invalid preprocessing token int b = cat(cat(1,2),3); What appears to be happening is that the compiler wraps the result of cat(1

I think the preprocessor handles files one by one and I can't figure out how to do it with includes, so I think it's impossible, but it would be great to hear other's thoughts. I have in a.cpp : #define A 1 and I want to use it from 2.cpp . EDIT: I cant modify first file. So for now i just have copied defines. But question still opened. Luchian Grigore Defines inside a source file aren't seen by other translation units. Implementation files are compiled separately. You can either put them in a header and include it use your compiler's options do it the sane way - extern const int A = 1; in an

How can I check the size of an unsigned in the preprocessor under g++? sizeof is out of the question since it is not defined when during preprocessing. This may not be the most elegant method, but one thing that you may be able to leverage is UINT_MAX defined in "limits.h". That is, ... if UINT_MAX == 65535, then you would know that sizeof (unsigned) = 2 if UINT_MAX == 4294967295, then you would know that sizeof (unsigned) = 4. and so on. As I said, not elegant, but it should provide some level of usability. Hope this helps. Based on Sparky's answer, here is a way that would look a bit nicer