I have some C++ code that uses some version of Google's GTest framework. This code used to compile fine with Visual Studio 2015. I just upgraded to VS2017, and now I get a bunch of errors like this:
error C2039: 'tr1': is not a member of 'std'
error C3083: 'tr1': the symbol to the left of a '::' must be a type
Is some compiler option needed to use std::tr1 in VS2017?
One option is to re-enable TR1; do this by defining the macro _HAS_TR1_NAMESPACE, as briefly mentioned in this blog article. If you're using an MSBuild project then this is best done by way of your project's Preprocessor Definitions setting; or if you're using a precompiled header, by defining it at the top of said PCH.
A better option is to inform GTest that your compiler supports C++11 by defining the macro GTEST_LANG_CXX11 to 1 before including any GTest headers; then it will use std::tuple rather than std::tr1::tuple*. (GTest's C++11-detection logic is __cplusplus-oriented, which VC++ has not yet updated despite being mostly C++11 and C++14 compliant. I would say this is a bug in GTest since it supports VC++ elsewhere throughout the configuration logic.)
* Not to mention the other C++11 features, which is why this is by far the better option ;-]
Googletest release 1.8.1 fixes this issue (in combination with VS2017 15.8.5).
Related
When I decided to switch from CLion to VS22, I found that the code analyzer swears at the new way of writing namespace, that avoid their nesting. I do not know how to make Visual Studio stop considering this an error, as a compiler I used clang and CMake to build, C++ standard is 23
Just for this issue, I suggest you don't use Clang and Cmake, create new project with MSVC and this problem will not occur.
Result:
I'm trying to port some OpenGL ES code from windows to Android using the Android NDK. I'm using Visual Studio 2017 and C++. What I did so far, I created a cross platform gles project in VS and removed the ios data. I'm putting one code file after the other and try to fix any errors I can find.
The issue I have is that is seems that math.h functions can't be found.
Here's some information that might be relevant:
Platform toolset is clang 3.8
Target API Level is android-21
Language standard is c++11
I have added m; as an option to linker library dependencies
If i include math.h I get:
use of undeclared identifier 'sqrt' (and all the other math.h functions I'm using)
If i include cmath I get:
no member names 'acos' in the global namespace (and all the other cmath functions)
Path for files (as found by Visual Studio):
c:\ProgramData\Microsoft\AndroidNDK64\android-ndk-r13b\platforms\android-21\arch-x86\usr\include\math.h
c:\ProgramData\Microsoft\AndroidNDK64\android-ndk-r13b\sources\cxx-stl\gnu-libstdc++\4.9\include\cmath
If I remove all math calls, it compiles.
Has anyone managed to use cmath in this context? If so, do you have any tips or point to what am I doing wrong?
Thanks.
If you #include <cmath> The methods are in std namespace so you should use std::acos etc.
I have not found a fix to the questions, but creating a project from the native android template allows you to use cmath without error, but you do need to add m; in linker input.
I am using MSVC++ 2013, and I installed the Clang plugin.
However, since I'm using STL, I'm getting bugs like this one:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\map:6:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xtree(1667,3) : error: cannot compile this try statement yet
_TRY_BEGIN
^~~~~~~~~~
They are quite a lot. In fact, there's only problems on the header files -- and it's what has me confused.
Is this an actual compiler bug? Incompatibility with MS' STL implementation?
If so, can I fix it, and how?
I thought of using GCC's or LLVM's headers, but I don't know how -- any pointers would be greatly appreciated.
Since you insist the environment is set up right, I looked up that exact macro that's not understood. That particular error can occur when the MSVC headers themselves include xstddef when _HAS_EXCEPTIONS is defined as 0. I can't find any other conditions on that macro, so it appears that your clang is compiling without exceptions.
This rings a bell in my head, and Clang had problems with exceptions for a long time on windows. Occording to this link, it still does in MSVC compatability mode: "Exceptions and SEH: Minimal. Clang can parse both constructs, but does not know how to emit compatible handlers. Clang cannot throw exceptions but it can rethrow them." http://clang.llvm.org/docs/MSVCCompatibility.html
I don't think llvm's libc++ can be compiled with msvc. Your best bet would be to try to use LLVM to produce MSVC compatible code that can (in theory) be linked with Visual C++ compiled code.
http://clang.llvm.org/docs/MSVCCompatibility.html
I'm trying to build Qt 5.2.0 from source using Visual Studio 2012. It is failing while compiling the following file:
/qtdeclarative/src/qml/jsruntime/qv4value_p.h
With the following error:
191: error C2039: _isnan: is not a member of std
Line 191 contains the following:
return doubleValue() && !std::isnan(doubleValue());
According to cppreference, std::isnan should be defined in the header cmath, since C++11. The Qt header file does include this header. When I inspect cmath in Visual Studio, I cannot see a function named isnan.
Am I right in concluding that VS2012 is missing this C++11 function? At first I thought I might have to enable C++11 support somehow, but according to this answer C++11 support is enabled by default. Given that binary downloads for Qt are available for VS2010 and VS2012, clearly it is possible to build with the respective compilers. Is there something I am missing?
isnan was implemented in Visual Studio'sstandard library starting with Visual Studio 2013.
There's most likely some sort of define to tell it that you don't have std::isnan available.
Found a lot on this error already, but my case does not get matched with any yet.
I am building a solution (having many projects) in debug mode, and one of them is throwing this error, I am using VS2010 and language is C++, .net version 4.0, earlier this project was compiled in vs2008 and then VS2010, and it was all ok, now I got a new machine which has just VS2010 installed and now facing this error.
Main thing to notice is:
Properties settings:
Project Configuration->General->/CLR is chosen
In C++->General-> No CLR support
I am having these settings since past, it's running all fine in my old machine in VS2010 only in the same debug mode.
What to do?
I am using Visual Studio 2013.
I had similar symptoms for a very simple C program. In the project properties I changed the General / Platform-Toolset setting from "Visual Studio 2010" to "Visual Studio 2013 v120" and that got rid of this error for me.
As the error indicates, precompiled headers are not compatible with /clr-compiled files.
You can disable precompiled headers for the cpp files that are compiled with /clr or for the whole project (C/C++ -> Precompiled Headers -> Precompiled Header : Not Using Precompiled Headers). I'm not sure what the difference is but both seem to work for me.
Doc is not exactly wrong, but I'm betting that's not what's going on here.
Do you by any chance have something like THIS:
#using namespace boost::asio;
...instead of something like THIS?
using namespace boost::asio;
Both "using" and "#using" have valid roles in Visual Studio-- but if you mean the pure C++ language keyword, be sure you are using the former! The latter is indeed used for managed code. See here:
https://msdn.microsoft.com/en-us/library/yab9swk4.aspx
Getting this wrong in Visual Studio 2015 has the following effects:
BUILD OUTPUT:
1>thingy.cpp(3): error C2006: '#using': expected a filename, found 'namespace'
1>thingy.cpp(3): fatal error C1190: managed targeted code requires a '/clr' option
Note that attempting to "satisfy" this in a fit of 4:00 AM frustration by removing the "namespace" keyword and quoting the value will result in only the second error.
(I think that's worth mentioning, because as both Visual Studio and the C++ language specification continue to change, people try all kinds of syntax that they know shouldn't work, and if it suddenly compiles, just assume the spec or the tools have changed in some way they haven't had time to keep up with-- especially if the error messages seem to have something to do with "features" they couldn't care less about, and don't use.)