In VS2015 is there an equivalent flag of GCC -fpermissive?
That's for a cpp application
Thanks
S.
VC++ compiler permissive by default, but you can disable it using compiler flag /permissive- starting with VS2015 Update 3
The theoretical equivalent is /Ze.
However, this allows Microsoft-specific extensions, whereas -fpermissive allows GCC-specific extensions. If you want your code to be portable, write portable code. It's that simple.
Related
I use Visual Studio 2019 for C++ development. Due to constraints of legacy systems that code will be deployed to, I am limited to using only C++11 language features (specifically GCC 4.8.5).
The default in VS2019 is C++14, which is obviously a super set of C++11. I can't see a way to specify C++11 only. This would be useful as a much faster way to see if I accidentally include newer C++ features than seeing things fail in the build system.
Is there any way to change this setting?
I am afraid it's not possible.
there is no plan to add a C++11 switch
Link: Standards version switches in the compiler
The compiler doesn't support standards options for C++98, C++03, or
C++11.
/Zc:__cplusplus
Is the c++ version you use tied to the version of compiler you have or IDE?
If it isn't either of those, how do I use c++ 11 on my IDE? How do i update what C++ version i use in my programs?
How do I check what version I'm using?
I know that printing the __cplusplus variable can tell me what version I'm using, but this doesn't answer my other questions, neither does it answer my third question, because: https://stackoverflow.com/a/14131551/10938047
Found this question, with the answer containing an outdated link.
Visual Studio 2012 __cplusplus and C++ 11
The C++ version you can use is obviously tied to the compiler you use. If your compiler doesn't support some newer standard then of course you cannot use it.
As for IDEs; some IDEs are tied to a specific compiler, some can use different ones.
Some compilers support multiple language versions but require you to explicitly enable anything newer than what they enable by default. For example; most older versions of GCC support C++17 just fine, but default to C++11 or C++14 unless you tell them to enable C++17 support via the -std=c++17 command line option.
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.
Say I have a open source C::B C++ (non-C++11, perfectly compatible with the 1998 ISO standard) project I've downloaded which is using MinGW/GCC (TDM-1 4.7.1 or 4.7.2 - doesn't work with newest version),; can I port the source files from it to Visual Studio 2010 and be able to make it work without massive code rewriting? Or there are certain cases in which it won't be possible? Or it depends on various things?
EDIT:
The code relies on additional external utilities and libraries such as:
Lua
SDL 2.0 + SDL Image 2.0
OpenGL
The most General and correct response is: It depends on various things.
What kind of project are you refering to? Is it wxWidget, QT4, GTK+, OpenGL?
How much do you use c++11?
Assuming that we are talking about a simple Console Application the easiest way to verify whether you can migrate to MSVC2010 is to switch compiler inside Code::Blocks project.
Select Project->Build Option... and under Selected compiler choose Microsoft Visual Studio C++ 2010. Afterwards try to recompile. The warning and errors will show you how easy will be the porting.
Of course you have to install Code::Blocks with MSVC2010 too.
EDIT: The OpenGL library is supported by MSVC2010 and libsdl has VC development libraries. However, things seem to be more complex with Lua. My guess is that you might start a substantial porting work here.
If the project was written using portable C++98 code you shouldn't have too much trouble. First, I would check you can compile in GCC with -std=c++98 -pedantic flags and fix any warnings to ensure you are not relying on any GCC extensions.
It also depends on the portability of any required libraries.
Try it!
If your code is standard-compliant and does not rely on any GCC extensions or GCC-specific libraries, then you should be fine out-of-the-box.
Note though that different compilers support C++ in different ways; for example, even Visual Studio 2013 has only passing C++11 support so if your program is a C++11 program with things like ranged-for and initializer lists in it then, depending on the version you're using, it's just not going to work without those pieces of code being rewritten to look more like C++03.
I actually made a mistake:
C::B indeed told me there were multiple errors in the compilation attempt with the MSVC2010 compiler, because the code included many Unix-only libraries, too intricately so to be easily avoided. Thus, I'm thinking of either making MinGW/GCC work in Visual Studio itself or sticking with C::B.
(Continues here: POSIX Headers (from MinGW project) in Visual Studio 2013)
Alternative tokens are valid c++ keywords, yet in Visual Studio 2013 the following emits a compilation error (undeclared identifier):
int main(int argc, const char* argv[])
{
int k(1), l(2);
if (k and l) cout << "both non zero\n";
return 0;
}
Since and or not have been around for quite some time, is there a reason for not implementing them?
You ask about the rationale. Here's one possible reason, not necessarily the one that most influenced the Visual C++ team:
Those are valid identifiers in C.
Microsoft's recommendation has long been to use C++ mode for both C and C++ code, rather than maintaining a modern C compiler.
Valid C code using these as identifiers would gratuitously break if they were compiled as keywords.
People trying to write portable C++ are mostly using /permissive- or /Za for maximum conformance anyway, which will cause these to be treated as keywords.
The workaround to treat them as keywords in /Ze by including a header file is easy and portable. (G++'s workaround -fno-operator-names isn't bad either, but putting the option in the source code rather than the build system is somewhat nicer.)
VS is nonconforming. This is old news.
To use alternative tokens, include the <ciso646> header. According to the standard, including this header is supposed to have no effect in C++. However, you do need it in VS. So it's safe to just include it always, whenever there is any chance that you might be compiling with VS.
Formally, these keywords are implemented and are supported intrinsically by the compiler without including any headers. However, for that you have to compile your source code in "more standard" mode of that C++ compiler, which means using the /Za option.
By intent, the /Za option is supposed to "disable compiler extensions". Of course, not supporting something that is supposed to be there in a compliant compiler cannot be formally qualified as a "compiler extension". Yet, that just the way things currently are.
Modern Visual Studio (or rather, MSVC) does support alternative tokens; however, it does so only in standards conformance mode. This mode comes with lots of goodies, so it should always be used.
To enable it, pass /permissive- to the compiler.
The answer below is obsolete. This is now supported, see above!
Previously, Microsoft’s position was1 that
#include of <iso646.h> (or ciso646) is how we support these keywords
And because “nobody” (before me, in 2007) ever requested this.
1 link currently defunct; left here for archival purpose.
(contemporary update)
I made a small test: A New "Windows Desktop Application" Project. The IDE (Visual Studio 2017 15.7.5) sets, by default, the following C++ language conformance settings: /permissive- /Zc:wchar_t /Zc:forScope /Zc:inline. In addition, I set the C++ Language Standard to ISO C++ /Latest draft (currently up to C++17). In addition, I added, in the main(), the following 2 lines:
bool a, b, c;
a = b and c;
It compiles the text-forms of the logical operators successfully. But when I altered the IDE Conformance mode to No (=> without /permissive-) and re-compile, the compiler marks: "error C2065: 'and': undeclared identifier".
By default, the /permissive- compiler option is set in new projects created by Visual Studio 2017 version 15.5 (December 2017) and later versions. It is not set by default in earlier versions. So if someone created a project prior to version 15.5 and by the time update the IDE to the latest version, still it required to set in the project this compiler option manually.
The /Ze compiler option, which is on by default, enables Microsoft extensions. The /Ze option is deprecated because its behavior is on by default. MSDN recommends to use the /Zc (Conformance) compiler options to control specific language extension features.