{"id":18103,"date":"2009-05-29T10:00:00","date_gmt":"2009-05-29T10:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2009\/05\/29\/alternatives-to-using-the-error-directive-to-check-whether-the-compiler-even-sees-you\/"},"modified":"2009-05-29T10:00:00","modified_gmt":"2009-05-29T10:00:00","slug":"alternatives-to-using-the-error-directive-to-check-whether-the-compiler-even-sees-you","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20090529-00\/?p=18103","title":{"rendered":"Alternatives to using the #error directive to check whether the compiler even sees you"},"content":{"rendered":"

\nIn response to my description of how you can\n\nuse the #error<\/CODE> directive to check\nwhether the compiler even sees you<\/A>,\nsome commenters proposed alternatives.\nI never claimed that my technique was the only one,\njust that it was another option available to you.\nHere are some other options.\n<\/P>\n\nscott suggested merely typing asdasdasd<\/CODE> into the header file<\/A>\nand seeing if you get an error.\nThis usually works, but it can be problematic if the code does not\nalready compile.\nAnd of course<\/I> it doesn’t compile,\nbecause the reason why you’re doing this investigation in the first\nplace is that\nyou can’t get your code to compile and you’re trying to figure out why<\/I>.\nConsequently, it’s not always clear whether any particular error\nwas due to your asdasdasd<\/CODE>\nor due to the fact that, well, your code doesn’t compile.\nFor example after adding your asdadsads<\/CODE> to line 41 of\nfile problem.h<\/CODE>, you get the error\nError: Semicolon expected at line 412 of file unrelated.h<\/CODE>.\nWas that caused by your asdasdad<\/CODE>?\nDoesn’t seem that way, but it actually was,\nbecause the preprocessed output looked like this:\n<\/P>\n

\nasdasdasd\nint GlobalVariable;\n<\/PRE>\n
\nAfter your asdasdasd<\/CODE>, all that was generated were a bunch\nof #define<\/CODE>s, #if<\/CODE>s, #endif<\/CODE>s,\nand #include<\/CODE>s.\nNone of them generate output, so the compiler proper doesn’t see anything;\nthe preprocessor ate it all.\nFinally, at unrelated.h<\/CODE> line 412, a header file finally\ntried to do something other than just define a macro,\nand it’s only then that the error is detected.\n<\/P>\n
\nBut if you can pick the new error out of the error spew, then go for it.\n(There are also obscure cases where an extra asdasdasd<\/CODE>\ndoesn’t introduce a new error.)\n<\/P>\n
\nSince the string #error<\/CODE> is shorter than asdasdasd<\/CODE>,\nand it works in more places, I just go with #error<\/CODE>.\n<\/P>\n
In response to my description of how you can use the #error directive to check whether the compiler even sees you, some commenters proposed alternatives. I never claimed that my technique was the only one, just that it was another option available to you. Here are some other options. scott suggested merely typing asdasdasd into […]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-18103","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
In response to my description of how you can use the #error directive to check whether the compiler even sees you, some commenters proposed alternatives. I never claimed that my technique was the only one, just that it was another option available to you. Here are some other options. scott suggested merely typing asdasdasd into […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/18103","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=18103"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/18103\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=18103"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=18103"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=18103"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nAnother suggestion came from\n\nMiguel Duarte who\nsuggested generating the preprocessed file and studying it<\/A>.\nThat helps, but the preprocessor output tends to be huge, and,\nas I noted in the base article,\n#define<\/CODE> directives don’t show up, so it can be hard for you\nto find your place.\nI also noted in the base article that\nif you use Visual Studio’s\nprecompiled header files,\nthe contents of the preprocessed output may not match what the compiler sees.\nIn fact, that’s the most common reason I’ve found for a line being ignored:\nYou put the #include<\/CODE> directive in a place that the\npreprocessor sees but which the compiler doesn’t see\nbecause you violated one of the\n\nprecompiled header consistency rules<\/A>,\nusually the\n\nsource file consistency rule<\/A>.\n<\/P><\/p>\n","protected":false},"excerpt":{"rendered":"