I have linked a FFTW library to the Unreal Engine project from this website. But now when I try to include the header file to my project, I get error:
'__GNUC__' is not defined as a preprocessor macro,
replacing with '0' for '#if/#elif'
I have no idea how to fix this. I don't want to mess with the code itself, because I think it is perfectly fine. Did I forget something when linking the library? I've also tried including the header file as a C library.
Any help would be appreciated.
IDE: Visual Studio 2017 Community
OS: Windows 10 Pro 64x
UE4 Version: 4.20
UnrealEngine seems to treat many warnings as errors, so this causes trouble when trying to use with 3rd party libraries that produce those warnings. Usually it's best to fix code to avoid the warning, but I would assume you can't for whatever reason.
In this particular case you could set:
bEnableUndefinedIdentifierWarnings = false;
Inside your *.Build.cs class constructor.
If this wasn't UnrealEngine, but still Visual Studio C++, you could also try putting this before code that causes the warning (e.g. before including header in which you get the warning):
#pragma warning(disable: 4668)
https://learn.microsoft.com/en-us/cpp/preprocessor/warning?view=vs-2019
Or disable it as compilation flag:
/wd4668
https://learn.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level?view=vs-2019
In general, if you get something you feel shouldn't be an error, search web if given error number (here C4668) is not usually a warning. If it is, then this allows quick hacks like above.
Related
I have large C++ project that I inherited and am trying to transfer it from Linux to Visual Studio on Windows. Managed to link required libraries, but one build error just baffles me.
In Linux, someone was including a header <error.h> everywhere, and I can't even find a documentation page to see what it is. First I thought is part of standard library, but I am now beginning to see it's a specific header for Linux OS.
So, how do I include it in Visual studio? I can't even find what it is and am tempted to just rearrange code to use stdexcept header, as the only thing these codes do is abort compilation and printout error messages by using some error(...) function from error.h.
error.h is a header from the GNU C Library. It is not specific to Linux, it is specific to glibc.
It is documented right here (search on the page for error.h).
The functions declared in error.h should not be used in portable code, so getting rid of code that uses them is not a bad idea. Alternatively, it is not difficult to implement them.
so i created a c++ linux console application on my x64 bit win 10 pro 10.0.17134 with wsl.
the project compiles no problem, without showing any errors. and debugging basic variable assignments works as expected;
then when i try to include any stl library e.g. #include <iostream> i get the following errors
128-bit floating-point types are not supported in this configuration
i am using Debug configuration with x64 bit mode.
i also tried googling the error, but i can't seem to find any related answer
i also tried using different c++ versions (c++17,c++11,etc...) but i still get the same error.
but even though i get these compilation errors, the program still runs correctly.
The compiler and the standard library are different things.
What you are seeing is a compiler that doesn't support 128 bit integers trying to use a std library that requires support for 128 bit integers.
The problem could be an Intelisense one, where Intelisense doesn't know that your compiler supports 128 bit integers or fails to properly exclude it or something. Your image shows you are seeing both Build and Intelisense errors; if the build succeeds that means those are Intelisense errors.
Intelisense is the MSVC tool that tries to parse and determine if you have errors in your C++ code. It doesn't use your compiler; rather, it uses a fast 3rd party compiler.
Turning Intelisense off may be the easiest way to get rid of those problems. Training Intelisense to get "proper" headers it understands is possible but quite difficult, and might be a many programmer-year project.
A quick hack would be to take your stdafx.h precompiled header, and do
#ifdef __INTELLISENSE__
using __float128 = long double; // or some fake 128 bit floating point type
#endif
but this can be an endless spiral.
There may also be ways to tell intellisense to ignore errors in certain files.
If it does not conflict with the rest of your code, you can set
__CUDACC__
in
Project Properties | Configuration Properties > C/C++ > IntelliSense | Preprocessor Definitions
This is if you are using GCC headers. The switch may be different for other sources.
As a tip, you can set the error output to Build Only. It defaults to Build + Intellisense, which as the answer above shows, is not necessarily what you want.
I have a growing project in CMake. It is time to link to a library, which at this time exists only in Windows, Linux functionality will have to wait. I am attempting to do this with preprocessor directives as recommended in an answer to this question:
// MyLibHeader.hpp
#ifdef WIN32
#include <windows.h>
#define ProcHandle HINSTANCE
#define LoadLib LoadLibraryA
#define LoadSym GetProcAddress
#else
// ... I'll fill these in with dlopen etc. when necessary
This is the first platform specific inclusion I have had to put in my code, and It seems there is more to it than this. This is generating this error:
C:\Program Files (x86)\Microsoft Visual Studio 8\VC\include\intrin.h(944) : error C2733: second C linkage of overloaded function '_interlockedbittestandset' not allowed
The error is repeated four times, twice in intrin.h, and twice in winnt.h. So here's my question. Are there other includes or preprocessor steps I need to take to get this to work inside windows (up to now it has been a basic console application) and is there something in CMake I can leverage to make this easier.
From what I've been able to scrape up with some help and some google, one solution is indeed to comment out the duplicate definitions of _interlockedbittestandset in initrin.h
This may have been fixed in later versions of Visual Studio.
You could look at the source code of CMake, there is a C++ class that does cross platform library loading. It is a BSD style license so you could just copy the code. Works on lots of platforms. The code is here:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/kwsys/DynamicLoader.cxx;h=c4ee095519fe27742a0a9a9e392be4ce095af423;hb=HEAD
I'm getting the linker error LNK2038 when trying to convert a VS2008 project to VS2010. This error occurs when two different projects are compiled in which one is using _DEBUG preprocessor macro, and the other is not. Basically I have a 3rd party library that only has release .libs, so when I try and use that library when building my project in debug mode I get this mismatch.
I understand why Microsoft is giving this error (STL iterator safety), however our project does not use Microsoft's STL, we use STLPort, so this error means nothing to our project. I just need a way to prevent it from doing this check.
Inside of the STL includes there is a file called yvals.h, which includes the #pragma detect_mismatch definition for the various _ITERATOR_DEBUG_LEVEL settings. That set of definitions is wrapped in an #ifndef _ALLOW_ITERATOR_DEBUG_LEVEL_MISMATCH, #endif. However, even if I define _ALLOW_ITERATOR_DEBUG_LEVEL_MISMATCH as a preprocessor macro for my entire project I'm still getting the same linker error. I can even alter yvals.h to define that macro and it does nothing (I'm assuming because the STL itself would need to be recompiled).
So my question is basically, what steps can I take make _ALLOW_ITERATOR_DEBUG_LEVEL_MISMATCH actually work as intended so that my project doesn't do this check anywhere when compiling in VS2010?
EDIT: I know this is a late response but I just found this post and realized I didn't post the solution. As others mentioned there was a mismatch in the libraries. As it turns out VS2010 changes the default directories for certain projects (I found a thread on MSDN at one point full of complaints about it), and that directory change had caused VS2010 to look in the wrong directory for the debug library, and it was finding the release library instead.
You must use the same version of the standard library, compiled with the
same options, if you expect to successfully link. If you use STLPort,
then you can only link with libraries which use the STLPort, not with
libraries which use the VC++ standard implementation. If you mix,
either you will fail to link, or you will get strange runtime errors.
The problem is that things like std::vector<>::iterator may be defined
completely differently; depending on where and how they are used, you
will find yourself using an instance constructed in a different library,
with a different layout.
I have recently started learning C++ and coming from a Ruby environment I have found it very hard to structure a project in a way that it still compiles correctly, I have been using Code::Blocks which is brilliant but a downside is that when I add a new header file or c++ source file, it will generate some code and even though it is only a mere 3 or 4 lines, I do not know what these lines do. First of all I would like to ask this question:
What do these lines do?
#ifndef TEXTGAME_H_INCLUDED
#define TEXTGAME_H_INCLUDED
#endif // TEXTGAME_H_INCLUDED
My second question is, do I need to #include both the .h file and the .cpp file, and in which order.
My third question is where can I find the GNU GCC Compiler that, I beleive, was packaged with Code::Blocks and how do I use it without Code::Blocks? I would rather develop in a notepad++ sort of way because that is what I'm used to in Ruby but since C++ is compiled, you may think differently (please give advice and views on that as well)
Thanks in advance, ell.
EDIT: I'm on Windows XP & thanks for the lighting fast replies!
To answer your questions:
The lines are include guards. They prevent the header file being included more than once in any given translation unit. If it was included multiple times, you would probably get multiple definition errors.
Header files are #included in .cpp files and in other headers. .cpp files are not normally #included.
The C++ compiler that comes with Code::Blocks is called MinGW GCC, and can be found in the bin directory of the MinGW installation. To find it, do a Windows search via explorer for 'g++'. To use it, you will need to put the directory it is in on your search path. Note the version of the compiler that ships with Code::Blocks is quite old - you can get a much more recent version from here.
That's an inclusion guard, to prevent a .h file from being included twice. Besides saving time, this is often in fact required to avoid defining things twice.
You should include only the .h. The .c file will be linked to your program in some form. For small programs, you can just pass all the .c files to gcc, but larger programs will involve intermediate .o files or even libraries (static or dynamic).
You can definitely work without an IDE. There are many ways to install the gcc compiler on Windows, including Cygwin and MinGW. I think you are correct that Code::Blocks comes with a gcc executable, but I don't know where it is or what version.
Those lines make it so that if a file is #included twice, everything will continue to work. That in turn lets you treat header-file dependencies as a simple directed graph, which is definitely easiest.
You don't #include .cpp files. (Well, not unless you're an evil programmer. Don't do it!)
I'll let others (or google!) tell you about gcc, but it might help if you were to describe what platform you're using.
All of your questions have been answered by others, except this:
I would rather develop in a notepad++
sort of way because that is what I'm
used to in Ruby but since C++ is
compiled, you may think differently
(please give advice and views on that
as well)
I think this is a very bad idea. A fully fledged IDE with an integrated debugger, jump to symbol definitions, refactoring capabilities, a profiler, intellisense and more is practically a must for any real world project.
And the absolute best is Visual Studio* with Visual Assist X**. Code::Blocks pales in comparison ;)
* If you study in a university you can usually get it for free through MSDNAA; otherwise there the Visual Studio Express edition whicih is free
** 30 days evaluation period