I recently read a question on IDE's here on StackOverflow, having always been an emacs user I decided to try out one of these ide's, namely netbeans for editing C++. It was so nice that I got a little carried away and wanted to edit OpenCL files in it to.
And now for my question. I have netbeans set up to process the opencl source files like C files but this causes a problem. The __kernel keyword makes the syntax checker act really strange.
Does anyone know how to make netbeans ignore a keyword in a specific(*.cl) file?
The following solution looks like its working:
#ifndef tan
#define __kernel
#define __global
#define __local
#define __private
#define get_global_id
#define get_global_size
#define get_local_id
#define get_local_size
#define barrier
#endif
Since tan is defined without a header, netbeans does not see it, and the keywords are available.
In order to make netbeans ignore a keyword, you could define ONLY_DEFINED_IN_NETBEANS in the preprocessor definitions entry in the code assistence options of the project, while not defining it elsewhere. Your code can then be modified as
#ifdef ONLY_DEFINED_IN_NETBEANS
#define __kernel
#define __global
#define __local
#define __private
#define get_global_id
#define get_global_size
#define get_local_id
#define get_local_size
#define barrier
#endif
The netbeans parser will ignore these keywords.
The same trick can be applied as a patch to the bug reported in netbeans on the __restrict__ keyword:
#ifdef ONLY_DEFINED_IN_NETBEANS
#define __restrict__
#define restrict
#endif
It is not the answer you want, but for temporary editing, just put lines like
#define __kernel
#define __global
#define __local
#define __private
at the beginning of the cl file. This is working in Eclipse. I think it will work in Netbeans, too.
Drawback: You need pay attention to remove the #define statements, otherwise the code will not work.
you can tell the C editor of netbeans to entirely ignore syntax errors but i don't think that you will have luck to teach netbeans the CL specific keywords.
tools->options->C++->build tools
duplicate the tool config
give it a name and remove all paths to the compiler
make it default
tools->options->C++->highlighting
uncheck highlight syntax errors and unresolved identifiers
Related
I am working with emscripten, which uses some macros that VS Code IntelliSense does not like. This is not unusual. So what I'd like to do is this:
#ifdef INTELLISENSE_IS_READING_THIS
#define PROBLEMATIC_MACRO
#endif
That way, I can keep the macros as is but VS code will stop whining.
Sad thing is I remember solving this exact problem in Visual Studio 2017 IntelliSense - with Microsoft's very own resource files - but unfortunately, it appears I did not ask this on stack overflown and instead solved it myself, so now I can't find it anymore.
𝙃𝙖! Found it. Just needed to craft a query that excludes all the questions about IntelliSense NOT reading or defining defines.
This is the way:
#ifdef __INTELLISENSE__
#define EMSCRIPTEN_KEEPALIVE
#endif
And this also works, but may also evaluate in Microsofts compiler:
#ifdef _MSC_VER
#define EMSCRIPTEN_KEEPALIVE
#endif
I am trying to Build the Hadoop 2.7.1 Sources in a Windows Server 2012 using Visual Studio Professional 2015.
The build of the winutils project failed, because an error in the libwinutils.c file. I installed the required software and set all of the environment variables. More or less I followed the directions from here:
Hadoop on Windows Building/ Installation Error
I commented out a line of the code and replace it as it can be seen below. Basically, I just stringify the "WSCE_CONFIG_DIR" and the "WSCE_CONFIG_FILE" but I removed the use of the macro that converts the strings to wide character, and it worked. But I really want to know why is the original code not working.
#define WIDEN_STRING(x) WIDEN_STRING_(x)
#define WIDEN_STRING_(x) L ## x
#define STRINGIFY(x) STRINGIFY_(x)
#define STRINGIFY_(x) #x
#pragma message("WSCE config is " STRINGIFY(WSCE_CONFIG_DIR) "\\" STRINGIFY(WSCE_CONFIG_FILE))
//const WCHAR* wsceConfigRelativePath = WIDEN_STRING(STRINGIFY(WSCE_CONFIG_DIR)) L"\\" WIDEN_STRING(STRINGIFY(WSCE_CONFIG_FILE));
const WCHAR* wsceConfigRelativePath = STRINGIFY(WSCE_CONFIG_DIR) "\\" STRINGIFY(WSCE_CONFIG_FILE);
Any comment would be highly appreciated.
Kind Regards,
Paul
I've just had this exact problem, and, after digging, here's the work-around. (I'm building 2.7.2, but I assume 2.7.1 isn't too different).
The initial problem is that WSCE_CONFIG_DIR and WSCE_CONFIG_FILE aren't defined. Normally they come from the project's preprocessor definitions and have the values $(WsceConfigDir) and $(WsceConfigFile), ie are copies of these environment variables. When building Hadoop using the .pom's these are set by \hadoop-2.7.2-src\hadoop-common-project\hadoop-common\pom.xml from the configuration values wsce.config.dir and wsce.config.file earlier in this file. The values from the .pom are ../etc/hadoop and wsce-site.xml.
To get round the problem I replaced $(WsceConfigDir) and $(WsceConfigFile) with these values in the libwinutils Preprocessor definitions.
This question was posted a year ago.
I am not sure the guy who asked this question solved this issue or not.
However, for someone who comes here because of the same error, I post how I have solved.
First of all, I have done steps what tiho's answer below link.
Hadoop on Windows Building/ Installation Error
and then I changed the order of code in libwinutils.c like below.
(libwinutils.c located in \hadoop-common-project\hadoop-common\src\main\winutils)
I guess the order of code matters to build with Window SDK 7.1 cmd.
revised: (revised one more makes sense though)
#define WIDEN_STRING_(x) L ## x
#define WIDEN_STRING(x) WIDEN_STRING_(x)
#define STRINGIFY_(x) #x
#define STRINGIFY(x) STRINGIFY_(x)
original:
#define WIDEN_STRING(x) WIDEN_STRING_(x)
#define WIDEN_STRING_(x) L ## x
#define STRINGIFY(x) STRINGIFY_(x)
#define STRINGIFY_(x) #x
and I executed 'mvn package -Pdist,native-win -DskipTests' command.
Please Change the Code as Below
(it worked for me while building HADOOP-2.10.0 in Windows 10)
#include <Ntdsapi.h>
#include <malloc.h>
#define WIDEN_STRING(x)
#define STRINGIFY_(x)
#pragma message("WSCE config is " STRINGIFY(WSCE_CONFIG_DIR) "\\" STRINGIFY(WSCE_CONFIG_FILE))
const WCHAR* wsceConfigRelativePath = WIDEN_STRING(STRINGIFY(WSCE_CONFIG_DIR)) L"\\" WIDEN_STRING(STRINGIFY(WSCE_CONFIG_FILE));
I'm writing a hook dll, which handles window drawing messages.
I found for Vista and above, some unknown message id are received by the hook dll, specifically 0x90 ~ 0x95.
I did some googling and found an msdn link and this, which told me what message they're:
#define WM_UAHDESTROYWINDOW 0x0090
#define WM_UAHDRAWMENU 0x0091
#define WM_UAHDRAWMENUITEM 0x0092
#define WM_UAHINITMENU 0x0093
#define WM_UAHMEASUREMENUITEM 0x0094
#define WM_UAHNCPAINTMENUPOPUP 0x0095
But I can't find definition of macro WM_UAHDRAWMENUITEM in any header files, the compiler complains about "undefined symbols". I did a global search on "WM_UAHDRAWMENUITEM" but found nothing.
At present I'm using 0x92 to handle this message.
My question is: how to nicely replace hard-coded 0x92 with a Windows-defined macro?
how to nicely replace hard-coded 0x92 with a Windows-defined macro?
Obviously, your installed version of the Win32 SDK does not have the macros, so you can't use them. But you have the #define values, so just copy/paste them directly into your own code. If you want, you can wrap them in an #ifdef so that if you ever upgrade to an SDK version that has them natively, the native macros will be used, otherwise the compiler will keep using your manual ones.
#ifndef WM_UAHDRAWMENUITEM
#define WM_UAHDRAWMENUITEM 0x0092
#endif
I'm pretty rusty in C++, so forgive me for any stupid comments/questions. Right now I'm working in Microsoft Visual C++ 2010 Express. I have two files - a source and a header - and VS is recognizing the header file when I include it, but it cannot find any definitions from within the header file. It shows me 'Error: identifier "RAW_PACKET_SIZE" is undefined'. The code was provided as a sample to work with a device's API, so it should work. I'm assuming the problem is with the VS setup. Here's some intro code form each:
recorder.cpp
#include <vector>
#include "APIW32.h"
#pragma comment(lib,"APIW32.lib")
int devID;
float* buf = new float[RAW_PACKET_SIZE]; // error is here, at 'RAW_PACKET_SIZE'
APIW32.h
#pragma once
#ifdef EXPORTS
#define API __declspec(dllexport)
#else
#define API __declspec(dllimport)
#endif
#define MIN_BW 0.301003456
#define MAX_BW 10100000
#define RAW_PACKET_SIZE 299008
UPDATE:
It appears that the error was only appearing in Intellisense, and not as an actual build error. Moral of the story - Intellisense is not always right!
Try float* buf = new float[RAW_PACKET_SIZE];
On a cross-platform project, I want to #include a header file whose name contains the name of the platform. I have a #define macro for the platform.
So for example, for
#define PLATFORM win32
I want
#include "engine\win32\devices_win32.h"
while for
#define PLATFORM linux
I want
#include "engine\linux\devices_linux.h"
I'm going with Richard Pennington's answer, minus one line of code - it works for me!
#define PLATFORM Linux
#define xstr(x) #x
#define str(x) xstr(x)
#define sub(x) x
#include str(sub(engine/PLATFORM/devices_)PLATFORM.h)
Usually, you would do something more like:
#ifdef WIN32
#include "devices_win32.h"
#endif
#ifdef LINUX
#include "devices_linux.h"
#endif
...rather than having a single PLATFORM definition which can be set differently depending on the platform.
#define PLATFORM Linux
#define xstr(x) #x
#define str(x) xstr(x)
#define sub(x) x
#define FILE str(sub(engine/PLATFORM/devices_)PLATFORM.h)
#include FILE
I'm not sure I'd use it, though. ;-)
I had to use Linux rather than linux because linux is defined as 1 in my compiler.
Well in practice, this could be achieved using something like
#define PLATFORM win32
#define INCLUDE_FILE devices_ ## PLATFORM
#define QUOTED_INCLUDE_FILE #INCLUDE_FILE
#include QUOTED_INCLUDE_FILE
but the the following rule would prevent you from doing this:
C comments and predefined macro names are not recognized inside a #include' directive in which the file name is delimited with <' and `>'.
C comments and predefined macro names are never recognized within a character or string constant. (Strictly speaking, this is the rule, not an exception, but it is worth noting here anyway.)