I am analyzing the code of a project.
There is some code gets compiled when SINIX is defined.
#ifdef SINIX
do something()
#else
do dosomethingelse()
#endif
Can anyone tell me if SINIX is OS specific define statement or it is a project specific.
Seems to be a project specific definition. My guess would be support for https://en.wikipedia.org/wiki/SINIX .
Grepping through the GCC sources, SINIX support was removed from GCC in 2003. Based on some ChangeLog entries, it seems GCC, back when it did support SINIX, set the predefined macros "SNI" and "sinix", but not "SINIX".
Related
I have exactly the opposite problem to VSCode turn of _WIN32 define - Visual Studio Code is failing to define _WIN32 for me. This is in a cross-platform project that is being developed on Windows with the Microsoft compiler, but needs to also be able to compile on Linux, so I have
#ifdef _WIN32
#include <windows.h>
failing, and VS Code then marks all references to Windows API types etc. with red underlines. (The include mechanism itself is working fine, e.g. it has no problem including regular C++ headers.)
Is there any known reason why VS Code on Windows might fail to define _WIN32? The question I linked suggests it should, and I haven't knowingly changed any settings related to it.
Most likely, the problem is VSCode is using the wrong C++ compiler to gather the predefined macros, and that compiler does not predefine _WIN32.
To check, in Command Palette (Ctrl+Shift+P), run "C/C++: Log Diagnostics". The output will show you which compiler VSCode found and what it detected as its built-in include path and preprocessor defines. If my guess is correct, the diagnostics will show the wrong compiler being used, and _WIN32 missing.
Assuming so, to solve this, use the command Palette to run "C/C++: Edit Configurations (UI)", then set "Compiler path" to point at your compiler executable (cl.exe in this case). That should solve the problem because VSCode will then query that compiler to determine the predefined macros, which will include _WIN32. Re-run the diagnostics to confirm.
(I just gave a similar answer to the question linked to in the question above, as I think both questions have essentially the same problem and solution, just with different details.)
I have some C++ code using NEON intrinsics. From what I have read, all you need to do is include arm_neon.h to your project.. And then I read that this arm_neon.h header is not actually readily available to you automatically, you have to get it from the web. So I found and added this version to my project:
http://clang.llvm.org/doxygen/arm__neon_8h-source.html
In my project's prefix.pch I added:
#import "arm_neon.h"
And when I try to build on my iPhone6 device (I am not using the simulator), I get a billion errors inside the arm_neon.h file:
Can anyone please explain to me what I am missing here?
You've been misinformed about being able to pick up an arm_neon.h from the Internet. Generally the header is not just compiler specific, but compiler version (even compiler revision) specific. For GCC it relies on a number of compiler built in function calls, and from your screenshot of Clang the same holds there. As you'd expect, if the name of these internal-only functions changes, the header will fail to compile.
What surprises me is that you're unable to use an include of whichever arm_neon.h ships with your build environment. The only thing I can think of that would cause this is the build command trying to build for x86_64 (for the simulator) but you say this isn't what is happening. It might be worth checking your build settings one more time.
If you're still not getting anywhere, remember that arm_neon.h is sometimes considered as a system header, so in C++ you might need to #include <arm_neon.h> rather than #include "arm_neon.h" to get the compiler to search the system paths.
I am working with Qt and Cryengine in visual studios. I am very new to large projects such as this one, but I am nearly to the point of actually adding something to this engine. My code compiles piece by piece, but when I try to compile my "Indie Game" project I get linking errors that after researching I still have no idea how to solve. I know the errors relate to my code InventoryGUI, because when I remove that file the project compiles fine with no linking errors.
This is my InventoryGUI code and the error that is displayed when trying to build Indie Game
http://imgur.com/hzmGdvH
This is the header file that it includes.
http://imgur.com/o22GHXg
I appreciate any help you guys can give on this. Of course, if you need to see different parts of my code, let me know and I will post it as well.
Thanks
Edit: Forgot to add that the function "createInventory()" calls the function InventoryGUI from a different project. I believe going between projects is very likely the cause of the errors.
if InventoryGUI class is defined in a shared library ("dll") and used in an executable, then you have to export its symbols (on Windows build that is).
so try something like :
#ifdef WIN32
# ifdef MY_LIB_EXPORTS
# define MY_LIB_DLL __declspec(dllexport)
# else
# define MY_LIB_DLL __declspec(dllimport)
# endif
#else
# define MY_LIB_DLL
#endif
class MY_LIB_DLL InventoryGUI
{
...
};
Then, the library defining InventoryGUI should have defined MY_LIB_EXPORTS.
For example if you use pro files system, it would look like
DEFINES += MY_LIB_EXPORTS
Other projects should not.
Check if there is a similar mechanism for the other classes of the library.
I am porting code from Solaris to Windows Visual Studios. To make the code compatible with both, I am using statements such as #if defined (Win32) and #ifdef(OSTYPE_solaris). I found where Win32 is defined, but I cannot find where OSTYPE_solaris is defined. I am thinking that I may not find the definition of it because I am looking for it on Visual Studios, and the header that defines OSTYPE_solaris is not available on Visual Studios. Am I correct in that assumption? If so, does anyone know where OSTYPE_solaris is defined? I googled it a bit, but I was not finding luck with this question. I am also having the same conundrum with OSTYPE_linux.
My guess is they are defined by compiler itself. If Solaris is using gcc as compiler, you could check compiler defined variables like this:
echo "" | gcc -E -dM -
But i think you should not ifdef by platform in most cases, it is better to use feature based defines like HAVE_SOCKET_H. But that requires much more work on multiplatform build system providing these defines and you may not need them.
Does anyone know an officially supported way to include debug-build only code in Qt? For example:
#ifdef QT_DEBUG
// do something
#endif
Basically like Q_ASSERT but for more complex tests.
I can't seem to find any documentation which says that the Qt framework guarantees to define a debug macro. If there isn't, what would be a sensible unofficial way to implement this feature project wide?
Qt defines QT_NO_DEBUG for release builds. Otherwise QT_DEBUG is defined.
Of course you are free to specify any DEFINES in your .pro files and scope them for either debug or release.
An alternative is to write in your project file something like:
debug {
DEFINES += MYPREFIX_DEBUG
}
release {
DEFINES += MYPREFIX_RELEASE
}
Then you will not depend on the Qt internal definition.
For check debug mode:
#ifdef QT_DEBUG
//Some codes
#endif
For check release mode:
#ifndef QT_DEBUG //<== Please note... if not defined
//Some codes
#endif