I am compiling a quite a big project using VxWorks6.8 C++ compiler. I am getting following warning
warning: extra tokens at end of #endif directive
#ifndef _OM_NO_IOSTREAM
#ifdef WIN32
#ifndef USE_IOSTREAM
#define USE_IOSTREAM
#endif USE_IOSTREAM
#endif WIN32
I am getting a quite a lot of these warnings.
Why i am getting these warnings and from C++ standard point of
view?
What is the good reason why compiler is warning for this?
What is the best way to fix this?
Thanks
#endif USE_IOSTREAM
#endif WIN32
Should be:
#endif // USE_IOSTREAM
#endif // WIN32
endif doesn't take any arguments. Such comments are placed only for better readability.
You also missed closing #endif // _OM_NO_IOSTREAM at the end.
Because you can't have anything after #endif
Also, you're missing an endif.
#ifndef _OM_NO_IOSTREAM
#ifdef WIN32
#ifndef USE_IOSTREAM
#define USE_IOSTREAM
#endif
#endif
#endif
#endif USE_IOSTREAM
#endif WIN32
// ^^^^^^^^^^^^ Compiler is warning about these extra tokens after endif directive.
There is no need of any identifier after #endif. The way to suppress those warnings is to remove them.
Normally you don't put text behind the #endif. (And you are missing an #endif for OM_NO_IOSTREAM)
http://msdn.microsoft.com/en-us/library/ew2hz0yd%28v=vs.80%29.aspx
Related
When testing for features in Visual Studio, I found this weird behaviour:
#ifndef __cpp_constexpr
#error Opposite day! //Compiler error
#endif
#define test_macro
#ifndef test_macro
#error But only for feature macros? //No compiler error
#endif
int main() {}
__cpp_constexpr is definitely defined, I used it in the actual program.
From my testing, it seems that with feature macros #ifndef behaves like #ifdef
and vice versa.
Is this a Visual Studio bug, or am I missing something?
Compiled in VS 2017, Visual C++14 or later, with C++17 standard enabled.
P.S. Intellisense is working as intended, it's only the compiler.
You are using incorrect pre-defined macro and pre-proc code. Next code can help:
#if defined(__GNUG__) && (__cplusplus > 201103L)
# define HAS_CONSTEXPR
#elif defined(_MSC_VER) && (_MSC_FULL_VER >= 190024210)
# define HAS_CONSTEXPR
#endif // __GNUG__
#ifndef HAS_CONSTEXPR
# error Opposite day! //Compiler error
#else
# define test_macro
# ifndef test_macro // useless by why not ?
# error But only for feature macros? //No compiler error
# endif
#endif
Suggesting to use boost config library. It is cross compiler, an you can solve it like this:
#ifdef BOOST_NO_CXX11_CONSTEXPR
# error Opposite day! //Compiler error
#endif
And it is going to work for all compilers supported by boost (according to the boost license, you can exam the source code and replicate is in you project)
I'm trying to forward calls from my DLL to another DLL. I can't find any documentation about how to do that with MinGW.
Using Visual C++ compiler I would go with:
#pragma comment (linker, "/export:DllInitialize=api.DllInitialize,#2")
Or by using a .def definition file:
EXPORTS
DllInitialize=api.DllInitialize
But none of these work when compiling with MinGW32. I am using Code::Blocks as IDE if it matters. How can I do this with MinGW32?
i am sorry, i added a bit too many double-quotes in the above code. instead it should be this way:
asm (".section .drectve\n\t.ascii \" -export:DllInitialize=api.DllInitialize #2\"");
If you need to use it many times, consider putting it in a macro, e.g.
#ifdef _MSC_VER
#define FORWARDED_EXPORT_WITH_ORDINAL(exp_name, ordinal, target_name) __pragma (comment (linker, "/export:" #exp_name "=" #target_name ",#" #ordinal))
#endif
#ifdef __GNUC__
#define FORWARDED_EXPORT_WITH_ORDINAL(exp_name, ordinal, target_name) asm (".section .drectve\n\t.ascii \" -export:" #exp_name "= " #target_name " #" #ordinal "\"");
#endif
FORWARDED_EXPORT_WITH_ORDINAL(DllInitialize, 2, api.DllInitialize)
FORWARDED_EXPORT_WITH_ORDINAL(my_create_file_a, 100, kernel32.CreateFileA)
you get the idea
here is how you can do it:
#ifdef _MSC_VER
#pragma comment (linker, "/export:DllInitialize=api.DllInitialize,#2")
#endif
#ifdef __GNUC__
asm (".section .drectve\n\t.ascii \" -export:\\\"DllInitialize=api.DllInitialize\\\" #2\"");
#endif
Note that "drectve" is not a typo, thats how it must be written however odd it may seem. By the way, this strange abbreviation is a microsoft's idea, not GCC's.
I'm using Qt with mingw to write a program that changes the registry, but when I call :
RegOpenKeyEx(HKEY_LOCAL_MACHINE,
"SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\DefaultProductKey",
0,
KEY_ALL_ACCESS|KEY_WOW64_64KEY,
&key);
Qt return :
`KEY_WOW64_64KEY' undeclared (first use in this function)
I had add "#include <windows.h>" but it still doesn't work.
I've find this post Error with RegOpenKeyEx, it's the same probleme than me, and the answer looks good.
But i'm not using windows xp i'm using 7(64bits).
So I trided to put in targetver.h :
#ifndef _WIN32_WINNT_WIN7
#define _WIN32_WINNT_WIN7 (0x0601)
#endif /* _WIN32_WINNT_WIN7 */
And it's still doesn't work ... :(
What can i do ? :(
Thanks :)
(sorry for my bad english)
You have to define the _WIN32_WINNT (not _WIN32_WINNT_WIN7) before including the windows.h header:
#ifndef _WIN32_WINNT
#define _WIN32_WINNT (0x0601)
#endif /* _WIN32_WINNT */
#include <windows.h>
Why would a #define statement in a .pch not be recognized by .mm files?
Results in "use of undeclared identifier" and "not declared in this scope" when attempting to reference the macro.
Pch looks like this:
#import <Availability.h>
#ifndef __IPHONE_3_0
#warning "This project uses features only available in iPhone SDK 3.0 and later."
#endif
#ifdef __OBJC__
#import <Foundation/Foundation.h>
#import <UIKit/UIKit.h>
#endif
#ifdef DEBUG
#define dNSLog(...) NSLog(#"%s %#", __PRETTY_FUNCTION__, [NSString stringWithFormat:__VA_ARGS__])
#else
#define dNSLog(format, ...)
#endif
I had the same problem, cleaning was not solving it.
After closing and restarting Xcode 4 everything was fine.
If that can help someone...
Turns out Xcode 4 wasn't actually cleaning the build. :(
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.