I am trying to compile a multiplatform C++ project with the Microsoft Visual C++ compiler (formerly the GCC was used, among other compilers).
Now I come across some preprocessor directives like this one:
#if __cplusplus < 201103L
// Define some macros of C++11 the code really relies on.
// [...]
#endif
Although I use Visual Studio 2015, __cplusplus is still defined as 199711L. This post from the Microsoft blog advises to check also for _MSVC_LANG.
To what extent does _MSVC_LANG >= 201402L not comply with C++11 ?
First, if you want a portable workaround, you can do:
#if __cplusplus < 201103L && _MSVC_LANG < 201103L
/* ... */
#elif __cplusplus >= 201402L || _MSVC_LANG >= 201402L
The comment you link states that it’s a bug that __cplusplus is not set correctly and that testing _MSVC_LANG is a stopgap. However, VC 2017 (19.10.25017) with /std:c++14 still sets __cplusplus to 199711. I’m not sure whether that means C++14 support is still not entirely complete, or if they just never got around to it.
The _MSVC_LANG macro is a Microsoft extension. Most other compilers do not set it, to make it easier to test that the compiler is or is not Microsoft. (One exception: clang++ --std:c++14 -fms-compatibility-version=19.10 will set both __cplusplus and _MSVC_LANG to 201402L, as that is its MSVC compatibility mode.)
ETA: Thanks to an anonymous commenter for pointing out that there is a /Zc:__cplusplus compiler switch, which sets the value of __cplusplus to match the variant you select.
Related
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".
I noticed that most of the standard library math functions are not accessible if I compile with cross ARM GCC version 4.9.* in cxx11 mode.
I tried to compile Eigen, as it has ARM optimizations but this just works with native compilers.
The reason is that these standard library functions are within guard flags, which could have been overrided like this till version 4.8.*
#pragma once
#pragma GCC diagnostic push
#define RAND_MAX __RAND_MAX
#pragma GCC diagnostic ignored "-Wshadow"
#pragma GCC diagnostic ignored "-Wfloat-equal"
#define _GLIBCXX_USE_C99_FP_MACROS_DYNAMIC 1
#include <AP_Eigen/eigen/Eigen/Core>
#include <AP_Eigen/eigen/Eigen/Dense>
#pragma GCC diagnostic pop
Since 4.9.* I get again complains, as there are even more utterly useless checks within the standard library. E.g. std::lgamma can not be found, or std::max is not existing ..
Does someone know a good way to bypass these guard flags in 4.9.*? Additionally, I wonder why cross GCC for ARM is doing this? There is no reason for this, as the code works 100% on these platform and it gets worse and worse with every compiler version ..
I have been working with CUDA 4.2 for a week now and I have a little problem.
When I write the __syncthreads() function it becomes underlined and looks like it is wrong...
Then if I put the mouse on the function it appears a message writing:
identifier __syncthreads(); is undefined.
but when i compile my project the output form build says:
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
So I am guessing that everything works fine but the fact that Visual Studio underlines the function is confusing me...How can I make Visual studio to know that this function is defined before the compiling process?
NOTE:The same thing happens with the kernel call: kernel<<<...,...>>> where the third "<" is underlined red too...
I know that this probably is a minor problem but i want to solve it...Thanks a lot!
I am using Visual Studio 2010 on win7 with Cuda 4.2 and Nsight 2.2
I added the following few lines to the top of the cu file and it began to recognize these functions. For some reason, Intellisense did not pick up this #define:
#ifndef __CUDACC__
#define __CUDACC__
#endif
I lost some color-coding in the code, but I no longer get strange false positive errors.
I am using CUDA 9.1 and Visual Studio 2017 15.6.4. The following code helps me eliminate the "__syncthreads() is undefined" error.
//for __syncthreads()
#ifndef __CUDACC__
#define __CUDACC__
#endif
#include <device_functions.h>
However, this method is not recommended because it may bring unpredictable side effects. Another method to solve this intellisense warning is:
#ifdef __INTELLISENSE___
// in here put whatever is your favorite flavor of intellisense workarounds
#endif
Reference:
__syncthreads(); is undefined need a help
I have CUDA 8.0 and Visual Studio 2015 and I had the same issue.
The below lines helped me:
After these lines: (already in code)
#include "cuda_runtime.h"
#include "device_launch_parameters.h"
I added these lines:
//for __syncthreads()
#ifndef __CUDACC_RTC__
#define __CUDACC_RTC__
#endif // !(__CUDACC_RTC__)
#include <device_functions.h>
It's based on this link: https://devtalk.nvidia.com/default/topic/1009723/__syncthreads-and-atomicadd-are-undefined-in-visual-studio-2015/
Experienced this when trying to define the body of __global__ functions in .cuh files. Moving the body of the functions into .cu source-file solved it.
However, it means that some of my templated functions can't use essential things like __syncthreads(), because templates might have to be defined in a .cuh header.
So, you might need to abandon function templates and instead stick to several functions, each with a slightly different name.
The other solutions either did not solve the same issue occurring in Eclipse 2021-06 with CMake 3.16.3, or produced the following warning with CUDA Runtime Version = 10.1:
/usr/include/device_functions.h:54:2: warning: #warning "device_functions.h is an internal header file and must not be used directly. This file will be removed in a future CUDA release.
The following gave proper highlighting and code completion in Eclipse, and it didn't produce compile warning:
#ifndef __CUDACC__
#define __CUDACC__
#include <device_functions.h>
#endif
I am writing an application in which I got to lock the computer screen (OS is Windows). My Application is in C++. For this purpose I used the LockWorkStation() API defined on msdn, http://msdn.microsoft.com/en-us/library/aa376875%28VS.85%29.aspx
I have included windows.h as told but still I am getting compilation error:
.\source.cpp(5) : error C3861: 'LockWorkStation': identifier not found
here is a sample code thats giving error.
#include <Windows.h>
int main()
{
LockWorkStation();
return 0;
}
Please tell me what I am missing here :(
I am using MS-Visual studio 2005.
Regards.
That function was not supported until Windows 2000. The header files are versioned to allow you to build for older versions of Windows. You're going to want to tell the compiler which minimum version of Windows you want to support as follows:
#define _WIN32_WINNT 0x0500
#define WINVER 0x0500
...
#include <windows.h>
If you open winuser.h, you can see that it is surrounded by #if(_WIN32_WINNT >= 0x0500) ... #endif, meaning that it is not available unless you are targeting Windows 2000 or higher.
See http://msdn.microsoft.com/en-us/library/aa383745(VS.85).aspx for more information on the version macros. There's also the new NTDDI_VERSION define where you can set them all at once.
I usually like to have a lot of warnings enabled when programming. However, some libraries contains code that easily causes warnings (.., python, Qt, ..). When compiling with gcc I can just use -isystem instead of -I to silence that. How can I do the same with the MS compiler? I know of the warning #pragma, but I would like a solution that does not involve compiler specific code all over the place. I also know that I can turn off specific warnings, but that is not what I want either.
BTW: isystem should be a tag of this question, but I was not allowed to do that..
SUMMARY: I want to see all warnings from my code, and no warnings from external code.
As of 2017-08-17 this still seems impossible.
I added a feature request here:
https://developercommunity.visualstudio.com/content/problem/96411/impossible-to-ignore-warnings-from-system-librarie.html
Update 2018:
The issue is now closed as fixed and is available in the standard MS VS installation [source].
A blog post from the MS team goes through the new features [here].
The solution from MS is flexible. You can not only differentiate using paths like you do with --isystem, but for example also by whether you use #include "" or #include <>. The blog post is worth a read to see all the various customization points.
This now exists under /experimental:external /external:I system_include_path /external:W0. See https://blogs.msdn.microsoft.com/vcblog/2017/12/13/broken-warnings-theory/ for many more details.
No clue why MS never picked this up.
We can only try voting on https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/14717934-add-a-cl-exe-option-for-system-headers-like-gcc-s
No, MSVC doesn't have an -isystem equivalent.
look at the output output from cl /? :
/wd disable warning n
/we treat warning n as an error
/wo issue warning n once
/w set warning level 1-4 for n
Note that this disables the warnings for your entire project; I remember when using Qt I'd rather change it's main header with the #pragma warning disable and enable at the end again so I could still see all warnings for my own source.
Edit the author edited his question, updated answer: there is no way to get your code with warnings and Qt code without warnings using compiler flags: how are you going to tell the compiler what is 'your' code?
Note that the above flags can be applied at file level as well, so this would allow you to disable the warnings for only those files in which you include Qt headers, but that still means you cannot see them for your own code in that files.
So I stay with the answer above; it is not quite pretty, but I'm pretty sure it's the only way: use #pragma at the beginning and the end of the Qt header(s). Either change the Qt headers (even more ugly), or choose a less invasive way like this:
//your source/header file
#include "shutuppqt.h"
#include <QString>
#include "enableallwarnings.h"
example "shutuppqt.h"
#ifdef MSVC
#pragma warning ( disable : 4222 ) //or whatever warning Qt emits
#else
//....
#endif
example "enableallwarnings.h"
#ifdef MSVC
#pragma warning ( enable : 4222 ) //or default instead of enable
#else
//....
#endif