MSVC 2019 has added a new _udiv128() intrinsic (documentation)
that I would like to use in my C++ code. However that intrinsic is currently not available in both clang-cl 9.0.0 and the Intel C++ compiler 2019 even though these compilers set _MSC_VER=1920 just like MSVC 2019.
Because of this issue the code below does not compile using both clang-cl and icl:
#include <immintrin.h>
#if _MSC_VER >= 1920
uint64_t res = _udiv128(a, b, c, &d);
#endif
Is there a way to detect MSVC using the preprocessor without detecting clang-cl, icl, ... I would like to avoid checking for _MSC_VER and then excluding all other C/C++ Windows compilers.
Ideally I would like to detect MSVC using a Microsoft specific macro that is only defined for MSVC but not for clang-cl, icl...
I can't speak for the Intel compiler.
Clang-cl defines _MSC_VER because it's trying to be a drop-in replacement for the MSVC compiler and to use the MS libraries that come with the compiler (e.g., the C RTL and the C++ Standard Library). Those library implementations depend on _MSC_VER, so clang-cl doesn't really have an option.
Options:
Seva's proposal from the comments will work for you. I understand is not your preferred solution, but it is an option. You could test it in one place so that you only have to update one place when the situation improves.
Try using the -fms-compatibility-version clang-cl flag to choose an older version. (If you don't provide this flag, clang-cl tries to discover you MSVC installation and then matches the compatibility flag to that installations libraries, which is probably why you're seeing exactly 1920.) This will prevent your #if _MSC_VER >= 1920 from triggering, but it could have side-effects if there are parts of the system libraries that require 1920-or-better.
Wait for clang-cl to implement _udiv128(). Better yet, propose a patch to get it done sooner.
Related
in codeblocks There isn't a C++17 option in the Build or Compiler options, only C++14
how can i enable it in codeblocks so that both coding tools and compiler support it?
Code::Blocks is not a compiler (but some glorified source code editor, sometimes calling themselves IDEs, which runs some external compiler).
You need a C++17 compiler (and once you've got one you might configure your IDE or editor to use it with the appropriate options). Try the very latest version of GCC (at least GCC 7, and perhaps wait for GCC 8) or Clang (wait for Clang5) and pass it the -std=c++17 option
Note that C++17 is the C++ standard slated to be published by the end of 2017. You may need to wait a bit (perhaps a year or two) for compilers and the standard library implementations to correctly and completely implement it.
Therefore I don't recommend using C++17 features on a project to be released soon (at end of 2017), since you are then building on β quality foundations. However, if you work on a large project to be released in 2019, you might take the risk of betting that the C++17 features you are using in it will become mature by that time.
Regarding standard libraries functions (such as std::filesystem) you'll easily find approximate equivalent (e.g. in native OS or POSIX APIs, in Boost, in Qt, in POCO, ...) that should be reasonably easy to port once C++17 implementations are common.
(I recommend using your compiler on the command line, or using make, ninja, or some other build automation system running compiler commands; details can be operating system and compiler specific.)
I'm working with a C++ library. The library's minimum requirements are C++03. I'm catching some warnings under Visual Studio 2015 regarding throwing destructors:
... algparam.h(271): warning C4297: 'AlgorithmParametersBase::~AlgorithmParametersBase':
function assumed not to throw an exception but does
... algparam.h(271): note: destructor or deallocator has
a (possibly implicit) non-throwing exception specification
The throw was by design in the 1990s when the code was written, but its showing its age now. We are kind of boxed in at the moment because we are not ready for a major version bump. (And its not as bad as it sounds prima fascia because it guards the throw based on uncaught_exception).
I want to remediate the issue by detecting C++ 11, and then adding noexcept(false). I was going to hide it in a macro so the code would compile under both C++03 and C++11.
The following does not work to detect C++11 under Visual Studio 2015. It does not produce the expected compiler error:
#if (__cpluplus >= 201103L)
# error Not C++11
#endif
Additionally, Microsoft does not appear to offer a Predefined Macros for detection of the language features.
How do I detect C++11 under Visual Studio 2015?
Related, I can detect the version of MSVC compiler via _MSC_VER. I think it will be _MSC_VER=1900 for VS2015. But it does not tell me anything about the language features.
Language features are important if the user enlists VS2015, but uses a downlevel C++ standard. Also, I don't have VS2013 to test, so I'm not sure a 1-off string like _MSC_VER=1700 is a good idea. I'd much rather learn if its C++11 or not.
I've run into similar issues on OS X and Linux with Clang and GCC compilers. See, for example, How to guard move constructors for C++03 and C++11? and What differences, if any, between C++03 and C++11 can be detected at run-time? But in this case, I want to detect it via the preprocessor.
Finally, this library does not use Autotools, Cmake or Boost. It has no external dependencies.
You can't detect the language version independently of the VS version, because VS does not offer language versioning switches- there's no such thing as VS2015 C++03 mode. The condition you're trying to detect (a downlevel standard with VS2015) does not exist, which handily explains why there is no feature macro to detect it.
Simply detect the VS version and switch off that.
I have a c++ program compiled in Visual Studio 2012. It contains the boost library. Now, I want to compile this using the g++ compiler. What are the things I must be aware of? Things that will most likely silently break my code in random places.
For example I was always assuming long is 4 bytes buy g++ treats this as 8 bytes. For this alone I need some changes.
And what version of gcc to use, 4.7.3, 4.6.4 or 4.8.2?
if you wrote valid and good C++ code without using specific libraries you should be aware of nothing.
Some of the things that you have to keep in mind. This list is not comprehensive but are those things that are on top of my mind when I read your question.
pragma once : When using g++, you should gaurd file inclusion by using #ifndef, #define and #endif guards.
Header inclusion : VS 2012 is very lenient and does not make a fuss of forward or backward slash while including headers. g++ will be strict in enforcing them.
If you are using Win32 threads / mutex, it is best to shift to std::thread. If you are using boost for threads, you are OK.
The version of gcc you can use and get away with depends on your usage of C++11 features. gcc was always ahead of Microsoft in implementing C++11 features and you should be OK with an older version of gcc too. I cannot answer this question unless I understand what c++11 features you are using in your code. It is safe to say that the more recent version of gcc will surely support what is available in Vs 2012.
Is there any C++11 compiler for Windows that supports the new C++11 type traits, like is_nothrow_move_constructible?
I was trying to write a container that supported it, only to find that none of my compilers (VC++ 2010, TDM MinGW32 GCC 4.6) support it...
For mingw, I would recommend STL's distro here (gcc 4.7.1). It comes with boost 1.50 also.
There also is mingw-w64 (a fork of the original mingw), I recommend rubenvb's personal builds here. Go to Toolchains targetting Win32 if you want the 32-bit versions. He also has personal builds of clang (clang support on windows is still very buggy. The x64 build will report linker errors so can only be used for better diagnostics, etc.)
STL's distro is very nice, however I find the mingw-w64 to have much better support for the win32 api (I have run into countless problems with the original mingw) and c++11 headers, such as <atomic> which is unsupported in the original mingw. mingw-w64 is much more actively developed (can create 32-bit and 64-bit binaries) and includes support for newer functions from windows vista and up.
For more info on the naming conventions of mingw-w64, see here and the faq.
Visual Studio C++ 2012 Beta supports a lot of C++11 type traits according to the reference. Have a look at the Visual Studio C++ 2012 Documentation However, I could not find is_nothrow_move_constructible documented there. It appears to be supported though.
GCC 4.7 does support is_nothrow_move_constructible you can try it on Windows by installing MinGW Distro.
Not an answer, but I just learned something from looking at the source code of GCC 4.7's type_traits header:
You don't even need is_nothrow_xyz in the first place!
The noexcept operator tells you if an exception throws.
So for these specific type traits, you can use that instead.
(Or at least in theory. Whether your compiler implements it is another matter.)
Does Intel C++ predefine some macro when compiling with Qstd=c++0x? Something like __GXX_EXPERIMENTAL_CXX0X__ in GCC? __cplusplus is still 199711.
Any way to detect C++0x compilation?
The Intel documentation indicates that it does define __GXX_EXPERIMENTAL_CXX0X__ on Linux, but does not define any macro on Windows.
On the current (2013-08-06) Intel Composer XE 2013 Update 5 for Windows, the list of preprocessor definitions includes
#define __INTEL_CXX11_MODE__ 1
if and only if C++0x mode is enabled.