I have been trying to enable syntax highlighting and see call hierarchy for code which is embedded in #ifdedfine block but I am not able to find the option for it. Could anyone please point me at how to do it? It works well for other code/files it's just the code in #ifdef block (e.g. #ifdef CPP_UNIT....#endif). Thanks.
Code in #ifdef blocks IS syntax-highlighted IF THE CODE IS ACTIVE (e.g. if you have a #ifdef Q_OS_WIN and somewhere in your included headers Q_OS_WIN is defined, the code will be highlighted. Otherwise, it will be grayed-out.)
As a test, try temporarily replacing #ifdef ... with #if 1. If the latter works, then you know that ... is undefined by that file or any included files.
Related
Can someone please clarify if I must add this code to the top of all my CPP files, or will it be sufficient if only one CPP file defines it?
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
You need to place this macro at the top of every translation unit1 for which you wish to track memory allocations. Macros are in effect from the point where they are defined to the end of the currently compiled translation unit (unless they are undefined prior to the end).
Also note that there's a __FILE__ macro involved, which already is a strong hint that the (non-compliant) replacement of new is per-file.
1 Translation units are the input to the compiler for which it generates object code. You can roughly think of a translation unit as a preprocessed source file (commonly with a file extension of .cpp, .cc, or .cxx).
Working on a Qt app on Windows. I include QVboxLayout in my source file only and this causes errors because its macro overwrites my method name.
foo.hpp
class foo
{
ChangeMenu();
}
foo.cpp
#include "foo.hpp"
#include "QVBoxLayout" // <--- this includes winuser.h
foo::ChangeMenu(){};
Now what happens is winuser.h has a macro
#ifdef UNICODE
#define ChangeMenu ChangeMenuW
#else
#define ChangeMenu ChangeMenuA
#endif // !UNICODE
This changes my function definition to ChangeMenuW but my declaration is still ChangeMenu.
How should I solve this? How can winuser.h define such a "normal" name as a macro?
Version of winuser.h is "windows kits\10\include\10.0.16299.0"
Pretty much any Windows API that deals with strings is actually a macro that resolves to a A or W version. There's no way around, you can either:
avoid including windows.h, but as you noticed, it creeps through;
brutally #undef the macro before defining/using your function; this is a fit punishment for hoarding such normal and non-macro-looking identifiers, but is tedious and some other code may actually need the Win32 function;
just accept it as a sad fact of life and avoid all the relevant Win32 APIs names; if you use Qt and follow its naming convention, it should be easy, as Qt functions use lowerCamelCase (as opposed to Win32 UpperCamelCase);
include windows.h explicitly straight in your header (possibly under an #ifdef _WIN32); this will make sure that your identifier will get replaced by the macro in all instances, so everything will work fine even if the compiler will actually compile a function with a different name; suitable for standalone projects, not suitable for libraries. (Thanks #Jonathan Potter for suggesting this)
You could take no care about this issue, Although your method name will be the same as the windows API, but the system will not mix them(just unify Unicode on both the place to define/call). If you call the ChangeMenu() directly, you will call the winapi, and if
foo f;
f.ChangeMenu();
or
foo::ChangeMenu();(static)
You will call your method.
And if you want to disable the winapi:
#ifdef ChangeMenu
#undef ChangeMenu
//code place that you define/call your own ChangeMenu().
#ifdef UNICODE
#define ChangeMenu ChangeMenuW
#else
#define ChangeMenu ChangeMenuA
#endif // !UNICODE
#endif
(It looks very tedious.)
I am working on a project with the library ADOL-C (for automatic differentiation) using gcc. Right now I am trying to recompile the library to use the parallelization features however the make process does not working apparently due to some preprocessor stuff.
I think the problematic line is :
#define ADOLC_OPENMP_THREAD_NUMBER int ADOLC_threadNumber
However I could not find what it means. Does it make a link between two variables? Also ADOLC_threadNumber has not been declared before...
The preprocessor doesn't even know what a variable is. All that #define does is define a short(long?)hand for declaring a variable. I.e., if you type
ADOLC_OPENMP_THREAD_NUMBER;
It becomes
int ADOLC_threadNumber;
It's just a text substitution. Everywhere in code where ADOLC_OPENMP_THREAD_NUMBER appears, it's substituted by int ADOLC_threadNumber.
As far as I see it, the line with the define itself is not problematic, but maybe the subsequent appearance of ADOLC_OPENMP_THREAD_NUMBER. However, to check this, we need to know more about the context.
#define is a directive used often in .h files,
it creates a macro, which is the association of an identifier or parameterized identifier with a token string.
After the macro is defined, the compiler can substitute the token string for each occurrence of the identifier in the source file.
#define may be associated with #ifndef directive to avoid to delare the identifier more than once :
#ifndef ADOLC_OPENMP_THREAD_NUMBER
#define ADOLC_OPENMP_THREAD_NUMBER int ADOLC_threadNumber
#endif
I have a large base of code for a series of embedded devices. Everytime we make a fix for one product, we merge-in the changes for others. Sometimes, some devices have the code under Macro's .. something like
#if DEVICE1
Do_This();
#elif DEVICE2
Do_That();
#else
Do_SomethingElse();
#endif
In the above case, I will have to merge-in the code under resspective macro. Sometimes, it is not very stright forward. So, after merging-in the changes.
During compilation time, is there any way to find whether the new added lines of code getting compiled or not?
cpp is the same preprocessor used by gcc. Call it manually with the same flags, it will output resulting (processed) code. Search interesting area to check what you want.
E.g. cpp foo.c | less.
My project compiles and runs OK in debug mode, but when I switch to release x86_64 compiling, I get compiler errors for attempts to setBounds using NSRect. (The errors read “incompatible type for argument 1 of setBounds”.)
There are lots of posts which I take to be suggesting to add the NS_BUILD_32_LIKE_64 macro definition above the Cocoa (Foundation) import, so that the “if NS_BUILD_32_LIKE_64” language in NSGeometry.h will be true and the necesseary typedefs will be used. So I added the macro definition to the h file of the offending class:
#define NS_BUILD_32_LIKE_64 1
#import <Cocoa/Cocoa.h>
And I still get the same compile errors.
I also tried converting explicitly from NSRect to CGRect, so that instead of this . . .
// rectIncomingSource is an NSRect
calayer.bounds = rectIncomingSource;
. . . I wrote this:
calayer.bounds = CGRectMake(rectIncomingSource.origin.x, rectIncomingSource.origin.y, rectIncomingSource.size.width, rectIncomingSource.size.height);
Same errors.
And why would setting bounds be the only problem? Per Apple docs, NSInteger and NSUInteger are the main conversion problem, and I use them all over the place, but the compiler doesn’t complain about them. So why would it choke on bounds?
I’m probably missing something really simple here — for which I apologize to the wizards. Any help for the blind?
The target info window gave me the clue to figure this out:
I was putting the NS_BUILD_32_LIKE_64 define in a particular class's h file. It should have been in the prefix header file, the one with the pch extension that usually resides in the project's "Other Sources."
#ifdef __OBJC__
#define NS_BUILD_32_LIKE_64 1 // this line added
#import <Cocoa/Cocoa.h>
#endif
Well, yeah, I suppose this was obvious. But maybe some other preprocessor neophyte will find this clarification helpful, so I won't delete the question.
And I still don't understand why setting bounds should have been the only problem. Maybe something to do with core animation?