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.
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
I am using Visual Studio 2017 and need to create code that is compatible to VS2008 (C++03 or C++98). Is there a switch to restrict MSVC to C++03 features?
I am using CMake and tried to set
set_property(TARGET tgt PROPERTY CXX_STANDARD 98)
But this seems only to make sure, that the compiler supports C++98 or newer.
Any solution, that checks if C++ code uses features that are newer than the features supported by VS2008 will work as well. I just need to make sure, that I do not accidentally use features that are too new.
MSVC only got the standard switch in one of the updates to VS2015 (Update 3 to be exact) which was more or less C++14 compliant, and as such there are only switches for standards starting with C++14 (plus a few later features that were already implemented at the time of the update). All older features are enabled unconditionally for backwards compatibility (and because of all the work required to retrofit already implemented features for previous standards for virtually no gain).
See this blog post for more information: https://devblogs.microsoft.com/cppblog/standards-version-switches-in-the-compiler/
Also, note that there were a lot of conformance improvements in newer versions of MSVC, so even with the std switches you could write code that wouldn't work or would behave differently on older compiler.
A better solution would be just to use VS2008 toolset from VS2017 visual studio, as explained here: https://devblogs.microsoft.com/cppblog/stuck-on-an-older-toolset-version-move-to-visual-studio-2015-without-upgrading-your-toolset/
That way you'll be certain your code compiles on the older toolset, while using up-to-date IDE.
The /std (Specify Language Standard Version) option is available in Visual Studio 2017 and later. Does it mean that previous versions of Visual Studio use particular versions of the C++ standard and, unlike gcc/clang, there's a 1:1 mapping between a VS version and the default C++ standard version provided by the compiler?
There is a blog post Standards version switches in the compiler that explains the introduction of the feature and what MSVC used to do previously:
Traditionally, we would release the compiler in a default mode that combines features striding several versions of the C++ language, e.g. C++98, C++03, C++11, C++14, etc. in addition to conformance improvement bug fixes. This can lead to situations where it is difficult to simultaneously upgrade to the newer and better compiler and at the same time move your code forward. We really appreciate the great feedback you’ve given us about our conformance improvements and new feature work. As the C++ standards committee is gearing up for a new C++ version, we’ve taken the initiative to help you state in your build systems or compiler command lines which version of C++ you are comfortable with while updating to the next version of Visual C++.
Visual C++ has made significant progress towards C++ standards conformance between the first release of Visual Studio 2015 and VS 2015 Update 3. We’ve fixed many issues with constexpr, improved expression SFINAE support, evaluation of initializer lists, variable templates, and more. Our standard library implementation has kept pace with features adopted into the post-C++14 standard draft. And we’ve implemented some major features currently under consideration by the committee, including C++ modules and coroutines. We want you to benefit from all this, but also we want you to consume these features at your own pace, while upgrading to this new update.
All post-C++14 features implemented in this update are off by default; those which were included in previous releases are left on to avoid causing your builds.
...
From what I gather /std:c++17 would be equivalent to clang/gcc -std=c++17 argument.
Some versions of msvc may not fully implement some versions of iso C++.
Depending on the Visual C++ compiler version or update level, certain C++14 or C++17 features may not be fully implemented or fully conformant when you specify the /std:c++14 or /std:c++17 options. For example, the Visual C++ 2017 RTM compiler does not fully support C++14-conformant constexpr, expression SFINAE, or 2-phase name lookup.
(cf: https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=vs-2017 )
So that's not exactly a "1:1 mapping between VS version and the default C++ standard version provided by the compiler".
You shouldn't rely on that.
Instead you should read the docs for the version of VS you're using.
Hope this answers your question.
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.
I find C++ is very controversial language in microsoft world. By default we have ISO C++ and then microsoft has Managed C++ and now C++ CLI.
I just know standard (ISO) C++. I don't know microsoft's version of C++.
I'm confused about interpretation of any c++ code by visual studio 2008 (or later). Thats why I'm using gnu tools for compiling my programs. But I do love Visual Studio.
What settings do I need to make if I only want to use
STRICTLY ISO C++
Managed C++ (its deprecated but I think they still support it for sake of backward compatibility)
C++ CLI (for .NET platform)
I want to build native assemblies using C++ not managed ones. So, is there anything else should I need to do?
Everything is in the build settings:
Common Language Runtime Support (/clr) - add or remove CLR support
Advance Compile as C++ Code (/TP) - to choose if c++ or c..
Language: Disable Language Extention - use this to force ANSI.
When you ask Visual Studio to make a C++ project, it makes a C++ project. C++/CLI is a different language.
VS2008 and earlier have implemented C++03 (or approximated it. Like almost every other compiler, there are bits of the standard that are not followed to the letter. A few features are not implemented (exception specifications, the export keyword or two-phase name lookup are the ones I can think of), and some proprietary extensions are added as well.
GCC, and most big compilers, do the exact same thing, so this isn't a case of Microsoft being "evil" as such. The extensions can be disabled, leaving you with a reasonably standards-compliant compiler.
VC2010 is adding a number of C++0x features (and at least in the beta, I haven't been able to find an option to disable these), so from a strict C++03 compliance point of view, it is going to be less compliant.
Dani's answer already tells you which settings to change to enable/disable different language dialects.