I found following code in library I'm trying to compile
#ifdef __GNU LesserC__
__attribute__((packed))
#endif
and
#ifdef __GNU LesserG__
#pragma interface
#endif
What the hell is __GNU LesserC__? Why is there the space, #ifdef afaik doesn't support anything like this. I trying googling it but I only found source code using it, no explanation what it is (was) supposed to do.
Most patches I found fix it by
- #ifdef __GNU LesserC__
+ #ifdef __GNU_LesserC__
but I would like to know what this actually is.
Oh, and the library is xbase.
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'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.
To handle platform specific code between Mac and Windows, WIN32 and APPLE are the terms to use, right?
So, thw code would look like this:
#ifdef _WIN32
// Windows code
#endif
#ifdef __APPLE__
// Mac code
#endif
What about Linux ?
How can i do that for all three? right
It's similar:
#ifdef __linux__
// Linux code
#endif
Since you are going to have either one of these three defined at a time, this should be ok for all three.
List of defines.
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
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.