Visual Studio Support For New C/C++ Standards

Visual Studio support for new C / C++ standards?

MS has a series of public replies to this, most of them blaming their users. Like this one:

https://devblogs.microsoft.com/cppblog/iso-c-standard-update/

Now, the Visual C++ compiler team receives the occasionally question as to why we haven’t implemented C99. It’s really based on interest from our users. Where we’ve received many requests for certain C99 features, we’ve tried to implement them (or analogues). A couple examples are variadic macros, long long, __pragma, __FUNCTION__, and __restrict. If there are other C99 features that you’d find useful in your work, let us know! We don’t hear much from our C users, so speak up and make yourselves heard

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=345360

Hi: unfortunately the overwhelming feadback we get from the majority of our users is that they would prefer that we focus on C++-0x instead of on C-99. We have "cherry-picked" certain popular C-99 features (variadic macros, long long) but beyond this we are unlikely to do much more in the C-99 space (at least in the short-term).

Jonathan Caves

Visual C++ Compiler Team.

This is a pretty sad state of affairs, but also makes sense if you suspect MS wants to lock users in: it makes it very hard to port modern gcc-based code into MSVC, which at least I find extremely painful.

A workaround exists, though: Note that Intel is much more enlightened on this. the Intel C compiler can handle C99 code and even has the same flags as gcc, making it much easier to port code between platforms. Also, the Intel compiler works in visual studio. So by scrapping MS COMPILER you can still use the MS IDE that you seem to think has some kind of value, and use C99 to your hearts content.

A more sensible approach is honestly to move over to Intel CC or gcc, and use Eclipse for your programming environment. Portability of code across Windows-Linux-Solaris-AIX-etc is usually important in my experience, and that is not at all supported by MS tools, unfortunately.

Is there any option to switch between C99 and C11 C standards in Visual Studio?

The only 'modes' supported by Visual C++ are: /std:c++14 mode for C++14 conformance (the default), /std:c++17 mode for C++17 support which is not quite complete as of VS 2017 (15.6). There is also a /std:c++latest mode which at some future point will include things in C++20. All of these should be combined with /permissive- for improved conformance.

To meet C++11 Standard Library conformance, Visual C++ has to support the C99 Standard Library, that's not the same thing as supporting C99 language conformance.

At some point to meet C++17 Standard Library requirements, Visual C++ will have to support the C11 Standard Library and again that's not the same thing as C11 language conformance.

See C++ Standards Conformance from Microsoft and C++11/14 STL Features, Fixes, And Breaking Changes In VS 2013

There is a comment thread in the post MSVC: The best choice for Windows where a Visual C++ project manager takes on the question of true 'C11' conformance.

Hi Onur,

C conformance is on our radar though we’re focusing on C++ conformance first.

We did some work in VS 2013 on C conformance, though we didn’t publicize
it a lot. That work included:

– C99 _Bool

– C99 compound literals

– C99 designated initializers

– C99 variable declarations

We’re nearing the end of our C++ conformance work. One of the last items
is a conforming preprocessor: a feature shared by C and C++. The
preprocessor will mark the beginning of our C conformance push as well
as the end of our C++98/11/14 conformance work.

Andrew

UPDATE: VS 2019 (16.8) will include /std:c11 and /std:c17 standards switches. See this blog post. Because the MSVC compiler does not support Variable-length Arrays (VLA) it does not claim C99 conformance. Note that these switches enable the new C99 preprocessor covered in this blog post.

How to enable C++17 compiling in Visual Studio?

There's now a drop down (at least since VS 2017.3.5) where you can specifically select C++17. The available options are (under project > Properties > C/C++ > Language > C++ Language Standard)

• ISO C++14 Standard. msvc command line option: /std:c++14
• ISO C++17 Standard. msvc command line option: /std:c++17

Visual Studio 2022 (MSVC C++20 and the /std:c++20 Switch - C++ Team Blog):

• ISO C++20 Standard. msvc command line option: /std:c++20

Any Visual Studio:

• The latest draft standard. msvc command line option: /std:c++latest

Which C99 features are available in the MS Visual Studio compiler?

Fortunately, Microsoft's stance on this issue has changed. MSVC++ version 12.0 (part of Visual Studio 2013) added support for

• _Bool type.
• Compound literals.
• Designated initializers.
• Mixing declarations with code.
• __func__ predefined identifier.

You can check the _MSC_VER macro for values greater than or equal to 1800 to see whether these features are supported.

Standard library support has been updated and is mostly complete since MSVC 14.0 (Visual Studio 2015). This release also added the inline keyword.

The restrict keyword, a conformant preprocessor and C11 support arrived in Visual Studio 2019 Release 16.8, but this doesn't include some mandatory C99 features made optional in C11.

Things that earlier versions already supported (I think since at least MSVC 7.1 / Visual Studio 2003):

• // style comments.
• long long type.
• Flexible array members (Microsoft called them "unsized arrays").
• Variadic macros (at least partially).

Things that are still missing:

• Variable length arrays (optional in C11, not planned).
• _Complex type (optional in C11, not planned).
• C11 multithreading (optional feature, on the roadmap).
• C11 atomic primitives and types (optional feature, on the roadmap).

How to enable C++17 support in VSCode C++ Extension

This has become much easier now. Search for cppstandard in your vs code extension settings and choose the version of C++ you want the extension to use from the drop down.

In order to make sure your debugger is using the same version, make sure you have something like this for your tasks.json, where the important lines are the --std and the line after that defines the version.

{
  "tasks": [
    {
      "type": "cppbuild",
      "label": "C/C++: g++ build active file",
      "command": "/usr/bin/g++",
      "args": [
        "--std",
        "c++17",
        "-I",
        "${fileDirname}",
        "-g",
        "${fileDirname}/*.cpp",
        "-o",
        "${workspaceFolder}/out/${fileBasenameNoExtension}.o"
      ],
      "options": {
        "cwd": "${workspaceFolder}"
      },
      "problemMatcher": ["$gcc"],
      "group": {
        "kind": "build",
        "isDefault": true
      }
    }
  ],
  "version": "2.0.0"
}

Note that if you're copying the above tasks.json directly, you'll need to have a folder named out in your workspace root.

Is C++11 available in Visual Studio 2017?

The Visual C++ 2017 compiler is C++11/C++14 compliant with a few specific exceptions:

• Expression SFINAE is implemented, but not complete. (Now complete in VS 2017 (15.7))
• Full C99 preprocessor support is limited due to some bugs with variadic macros
• Two phase name lookup is in VS 2017 (15.3 update) but is incomplete and only active when using /permissive- (Now complete in VS 2017 (15.7))

The compiler does not offer a specific C++11 mode and defaults to C++14, but that standard is fully inclusive of C++11. C++17 support is in progress, and requires you use the /std:c++17 or /std::c++latest switch.

std::stoi requires you include the appropriate header, specifically <string>> Either you forgot to include that header -or- you didn't deal with the namespace resolution (either explicitly as std:: or via using namespace std;)

See C++17 Features And STL Fixes In VS 2017 15.3 for the latest status of C++11/C++14/C++17 standards conformance as of the VS 2017 (15.3 update)

UPDATED: For the latest on Visual C++ conformance, see Microsoft Docs.

Now that you have posted your code, I see that the problem has nothing to do with which standard is supported. Your problem is that you don't know the secrets of how Precompiled Headers work.

Change:

#include <string>
#include "stdafx.h"

to:

#include "stdafx.h"
#include <string>

-or- add #include <string> to the precompiled header stdafx.h directly.

See Creating Precompiled Header Files

---

Related Topics