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];
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
(Visual Studio 2010 / Visual C++ / Windows 7)
example.cpp:
#include <Shlobj.h>
#pragma comment (lib, "Shell32.lib")
...
void example()
{
SHGetKnownFolderPath(...) // undefined
}
I'm doing everything according to documentation and what I see in other threads, but it still doesn't work.
I had exactly the same problem. Another project with the same code and ancillary files (but different includes) was working.
Putting #include <Shlobj.h> at the top of the file solved the problem.
It might not be replicable though, as it should have worked without doing that. Probably another Visual Studio bug.
Try putting following statement before all includes:
#define WINVER 0x0600
#define _WIN32_WINNT 0x0600
Since the documentation says it needs Vista/2008 minimum.
first of all I have to mention that I'm new to c++ but within my course of studies I have gained some experiences with programming.
Currently, I'm working on a plugin for a datastream between vicon blade 1.7 and unreal engine 4.4.3. This should be done by using the Vicon Datastream SDK v 1.4 which contains a header file, a library and a .dll file.
Right now, I'm having problems with compiling my basic plugin.
The Vicon DataStream SDK was build within an older version of visual studio than 2010. So I want to know if there is any possibility to go on working with the vicon sdk in visual studio 2013? Should I force the sdk to use the latest .dll in visual studio and if so how do I do that?
I already tried to go on working with the sdk ignoring the problem I've mentioned before.
When I built the project without changing the header file of the sdk I'm getting this error:
Error 2 error C2059: syntax error : 'constant'
Here are the affected rows:
#ifdef WIN32
#ifdef _EXPORTING
#define CLASS_DECLSPEC __declspec(dllexport)
#else
#define CLASS_DECLSPEC __declspec(dllimport)
#endif // _EXPORTING
#elif defined( __GNUC__ )
#if __GNUC__ < 4
#error gcc 4 is required.
#endif
#define CLASS_DECLSPEC __attribute__((visibility("default")))
#else
#define CLASS_DECLSPEC
#endif
#include <string>
namespace ViconDataStreamSDK
{
namespace CPP
{
...
}
}
If I redefine the second namespace to 'UCPP' I'm getting a huge list of errors like this one:
Error 2 error LNK2019: unresolved external symbol
"__declspec(dllimport) public: __cdecl
ViconDataStreamSDK::UCPP::Client::Client(void)"
I think it's because CPP is already defined in unreal engine but because of the dependency of the header file to the .dll file in the sdk the definition of the namespace is unchangeable in the sdk.
Is that expectation correct or am I on the wrong track?
I had similar problems with the name space. To fix that I did this in my UE4 Plugin header file before including the Vicon DataStreamSDK
#define UCPP CPP
#undef CPP
#include <Client.h> //Vicon DataStreamSDK
.....
At the end of this file I redifined the CPP macro
#define CPP PCPP
This compiles and works fine with no problems
I'm using visual studio 2010 to build a .dll. I wrote up a trial as:
// trialDLL.h
#ifndef TRIALDLL_H_
#define TRIALDLL_H_
// ... MyMathFuncs class definition omitted
#ifdef __cplusplus
extern "C"{
#endif
#ifdef TRIALDLL_EXPORT
#define TRIALDLL_API __declspec(dllexport)
#else
#define TRIALDLL_API __declspec(dllimport)
#endif
TRIALDLL_API MyMathFuncs* __stdcall new_MyMathFuncs(double offset);
TRIALDLL_API void __stdcall del_MyMathFuncs(MyMathFuncs *myMath);
TRIALDLL_API double __stdcall MyAdd(MyMathFuncs* myMath, double a, double b);
// some other similar stuff
#ifdef __cplusplus
}
#endif
#endif
And the triallDLL.cpp file:
// trialDLL.cpp
#include "trialDLL.h"
TRIALDLL_API MyMathFuncs* __stdcall new_MyMathFuncs(double offset)
{
return new MyMathFuncs(offset);
}
TRIALDLL_API void __stdcall del_MyMathFuncs(MyMathFuncs *myMath)
{
delete myMath;
}
TRIALDLL_API double __stdcall MyAdd(MyMathFuncs *myMath, double a, double b)
{
return myMath->Add(a, b);
}
// ... some other definitions
With these two files in the project, I added a property sheet to the project through visual studio 2010 property manager and added TRIALDLL_EXPORT to user macros. After all these, the nice Intellisense gives me error for each function defined in the .cpp file and complains "error: a function declared 'dllimport' may not be defined". So it appears that Intellisense doesn't find TRIALDLL_EXPORT defined. I thought it might make a difference if I actually build the project, but the result suggests the same error: "error C2491: 'new_MyMathFuncs' : definition of dllimport function not allowed". Then it is clear that the macro TRIALDLL_EXPORT is still not defined in compiling time.
After failing to add macro through visual studio, I also tried putting code line: #define TRIALDLL_EXPORT in trialDLL.cpp but it didn't help either. I wonder what's the proper way to do this? How do I inform the compiler that the micro is defined so that TRIALDLL_API evaluates to dllexport rather than dllimport?
Also, if I can build the .dll successfully, is there any systematic way to test/verify the functionality of the .dll?
Thanks for any help in advance! (Although I know it's an issue here on stackoverflow to put appreciation in the question, I feel myself impolite not to do so. Forgive me for any inefficiency caused by these lines.)
"User macros" in VS property sheets have nothing to do with preprocessor macros. Put TRIALDLL_EXPORT into the property sheet's section C/C++ > Preprocessor > Preprocessor Definitions
"User macros," which can only be defined in property sheets, allow you to create your own "variables" usable in Visual Studio properties, similar to the built-in ones $(TargetName), $(SolutionDir) etc.
As said in this Microsoft article, you cannot apply the __declspec(dllimport) keyword to implement a function. You should use it only in the declaration. For example:
// function declaration
void __declspec(dllimport) funcB();
// function definition
void funcB() {
//funcB code
}
Put
#error Where is my macro?
in the #else block of the header. Then experiment with the project settings or the #define until you get it right. Did you perhaps only add the property sheet to one configuration? Did you put the #define at the very top of the file? Do you have any PCH stuff that causes it to ignore your settings? And so on.
The code looks okay, and must work if TRIALDLL_EXPORT is actually defined. You most probably messed up that somehow (like set it for a different configuration or for just one file) or did not rebuild.
If you're completely lost, ask for the preprocessor output, and look at that. As with define there can not be dllimport around at all, the error is also impossible.
EDIT: I just noticed you wrote _I also tried putting code line: #define TRIALDLL_EXPORT in_ trialDLL.cpp. I thought you put it at top of the header for trial. Try that first just to see that it works fine. Then you can remove it after you found the proper place.
Please look at the following file: (it is a complete file)
#ifndef TEES_ALGORITHM_LIBRARY_WRAPPER_H
#define TEES_ALGORITHM_LIBRARY_WRAPPER_H
#ifdef _TEES_COMPILE_AS_LIB
#include <dfa\Includes\DFC_algorithms.hpp>
#include <DFA\FuzzyClassifier\FuzzyAlgorithmIntialization\InitFuzzyAlgorithm.hpp>
typedef teesalgorithm::tees_fuzzy_algorithms algorithms_switchyard_class;
#else
#include <DFA\Includes\commercial_algorithms.hpp>
//An incomplete class to hide implementation
class algorithms_switchyard_class;
#endif
class AlgorithmLibraryWrapper {
algorithms_switchyard_class * algorithmPtr_;
typedef teesalgorithm::tees_paramObj paramObj_type;
typedef teesalgorithm::tees_errorObj errorObj_type;
typedef teesalgorithm::tees_statusObj statusObj_type;
typedef teesalgorithm::tees_dataObj dataObj_type;
typedef teesalgorithm::tees_outputObj outputObj_type;
public:
AlgorithmLibraryWrapper(const std::string& sAlgName, paramObj_type& paramObj, errorObj_type& errObj, statusObj_type& statusObj, const char* sFilePath);
static bool dataReader(const std::string& sFileName, dataObj_type& dataObj, errorObj_type& errObj, statusObj_type& statusObj);
bool runalgorithm(const dataObj_type& dataObj, outputObj_type& outObj, errorObj_type& errObj, statusObj_type& statusObj);
~AlgorithmLibraryWrapper();
};
#ifdef _TEES_USE_COMPILED_ALGORITHM_LIB
# ifdef _MSC_VER
#if _MSC_VER < 1400 // If VC 2003
#ifdef _DEBUG
#error No AlgorithmLibWrapper libraries compiled for this version of VC
#else
#error No AlgorithmLibWrapper libraries compiled for this version of VC
#endif
#elif defined(UNDER_CE) // Win CE
#ifdef _DEBUG
#pragma comment( lib, "AlgorithmLibWrapperCEd" )
#else
#pragma comment( lib, "AlgorithmLibWrapperCE" )
#endif
#else // If VC 2005
#ifdef _DEBUG
#pragma comment( lib, "AlgorithmLibWrapperd" )
#else
#pragma comment( lib, "AlgorithmLibWrapper" )
#endif
#endif
#endif
#endif
#endif //TEES_ALGORITHM_LIBRARY_WRAPPER_H
I am getting the following errors; I don't know why. I manually counted the preprocessor directives also.
AlgorithmLibraryWrapper.hpp:10:1: unterminated #ifdef
AlgorithmLibraryWrapper.hpp:7:1: unterminated #ifndef
I am using the poor vxWorks gcc compiler. Please let me know if the fault is mine or the compiler's.
It could be that the problem is in the included files (if there actually are unbalaced #if/#endifs.
I would try preprocessing with another compiler. You can use gcc for that, doesn't matter it wouldn't compile. Just get gcc (or MinGW if you're on Windows) and run
cpp -Iinclude_direcories your_file
Or, if you don't like gcc, get MSVC Express edition. Again, you can preprocess code that even doesn't compile, so no problem with nonworking library etc.
Most compilers have an option that will give you the output from the preprocessor so you can check what it's doing. For example,
gcc -E file.c >file.preproc
will give you the pre-processed source so you can check the balancing of #if against #endif.
At a guess, one of the files you are #including from this one has a mismatched #ifdef/#endif pair. You need to look at all the files (as the preprocesor does), not just this one.
As others have noted, this is most likely due to mismatched include guards.
If the files you are including are under your control (i.e. not part of a 3rd party closed source library), you could consider replacing the #ifndef et. al. guards (which are used to prevent multiple inclusion) with #pragma once. This will eliminate the possibility of having mismatched preprocessor directives.
One caveat of this is that pragma once is non-standard, so it will only work if your compiler supports it.
I have tried to compile your source using vs 6.0 but did not get the error you have mentioned. As others said may be the error is coming from the included header file . For me to get your code compiled i need to comment the above header.
Please check the above header once.
I'd debug this by commenting out sections one by one and trying to identify which section is causing the error.
It could be your compiler does not like the nested #ifdefs or does not interpret the syntax correctly. Maybe it doesn't like the #pragmas.
This is a long shot, but in your source file you have the following line:
# ifdef _MSC_VER
where there is whitespace between the '#' character and the directive name (ifdef). This is valid in C/C++; however, it's not too commonly seen so I wouldn't be very surprised if the odd compiler choked on it.