We’re happy to have shipped Visual Studio 2015 Update 2 (grab a copy here!). This is a quick glance at the Visual C++ bugs resolved that were reported on the Microsoft Connect portal. We have fixed 330 Connect and VS Feedback bugs in the compiler frontend, backend, and libraries; and an additional 30 bugs in the IDE for Visual Studio 2015 Update 2.

These bugs were submitted by the users in the community. Although we didn’t fix every reported customer issue (yet!), we appreciate that our customers take the time to file bugs on our product, and we try to prioritize the bugs that come from the community. If you encounter issues while using our compiler, please file bugs! It helps us know which issues should have the most attention.

Compiler Frontend, Backend, and Libs Fixes

IDE Fixes

We update the Visual C++ Web Compiler regularly, so you can use it to check the status of a bug against a recent build of our compiler.

If you encounter any issues using Visual Studio Update 2 (or any Visual Studio version, for that matter!), please submit feedback using the Microsoft Connect webpage.

Would like to thank all who have tried out the C/C++ extension in Visual Studio Code and have already provided rich feedback on their experiences, filed issues with us. Pairing with the Visual Studio Code 1.0 announcement we are also updating the C/C++ extension today in VSCode with the following improvements based upon the feedback that we have heard so far:

Code Editing

Debugging

Update your extension now!

If you already using the C/C++ extension, you can update your extension easily by using the ext update dropdown. This will display any available updates for your currently installed extensions. Simply click the Update Extension button in the lower right for the outdated extension and the update will be installed and you’ll be prompted to restart VS Code.

Wrap up

For more information about the overall VSCode C/C++ experience you can refer to our original blog-post and documentation which has been updated w.r.t. changes. Please help us by continuing to file issues at our Github account and keep trying out this experience and if you would like to shape the future of this extension please join our Cross-Platform C++ Insiders group where you can speak with us directly and help us on this venture.

We’re happy to have shipped Visual Studio 2015 Update 2 (grab a copy here!). This is a quick glance at the Visual C++ bugs resolved that were reported on the Microsoft Connect portal. We have fixed 330 Connect and VS Feedback bugs in the compiler frontend, backend, and libraries; and an additional 30 bugs in the IDE for Visual Studio 2015 Update 2.

These bugs were submitted by the users in the community. Although we didn’t fix every reported customer issue (yet!), we appreciate that our customers take the time to file bugs on our product, and we try to prioritize the bugs that come from the community. If you encounter issues while using our compiler, please file bugs! It helps us know which issues should have the most attention.

Compiler Frontend, Backend, and Libs Fixes

IDE Fixes

We update the Visual C++ Web Compiler regularly, so you can use it to check the status of a bug against a recent build of our compiler.

If you encounter any issues using Visual Studio Update 2 (or any Visual Studio version, for that matter!), please submit feedback using the Microsoft Connect webpage.

Would like to thank all who have tried out the C/C++ extension in Visual Studio Code and have already provided rich feedback on their experiences, filed issues with us. Pairing with the Visual Studio Code 1.0 announcement we are also updating the C/C++ extension today in VSCode with the following improvements based upon the feedback that we have heard so far:

Code Editing

Debugging

Update your extension now!

If you already using the C/C++ extension, you can update your extension easily by using the ext update dropdown. This will display any available updates for your currently installed extensions. Simply click the Update Extension button in the lower right for the outdated extension and the update will be installed and you’ll be prompted to restart VS Code.

Wrap up

For more information about the overall VSCode C/C++ experience you can refer to our original blog-post and documentation which has been updated w.r.t. changes. Please help us by continuing to file issues at our Github account and keep trying out this experience and if you would like to shape the future of this extension please join our Cross-Platform C++ Insiders group where you can speak with us directly and help us on this venture.

We are excited to announce the preview release of a new, advanced code optimizer for the Visual C++ compiler backend. It provides many improvements for both code size and performance, bringing the optimizer to a new standard of quality expected from a modern native compiler.

This is the first public release and we are encouraging people to try it and provide suggestions and feedback about potential bugs. The official release of the new optimizer is expected to be Visual Studio Update 3, while the release available today is unsupported and mostly for testing purposes.

How to try it out

The compiler bits with the new optimizer are very easy to get: just install the latest VisualCppTools package using NuGet. Details about how to do this are available in this blog post. Once installed, compile your applications the usual way – the optimizer is enabled by default on all architectures.

Reporting bugs and suggestions

We are hoping to get as much feedback as possible about bugs you have found or suggestions you may have. If you believe you found a bug, you can confirm it’s caused by the new optimizer by using the following undocumented flag to disable it: -d2SSAOptimizer-

• In the Visual Studio IDE, add the flag to the project Property Pages -> C/C++ -> Command Line -> Additional Options text box
• If you compile from command line using cl.exe, add the flag before any /link options

If the bug does not manifest anymore with -d2SSAOptimizer-, please follow the steps below:

• Submit a bug report using the Connect website
• Prefix the title with [SSA Optimizer]
• Attached details such as the compiler version, compile flags, and the source code that reproduces the bug in the form of pre-processed files or a linkrepro. Bruce Dawson’s blog has a great post about producing high-quality bug reports
• You can also send an email directly to gratilup@microsoft.com

Why a new optimizer?

The main motivation for a new optimizer framework was the desire to have more aggressive optimizations, such as ones that take advantage of more compile-time information and modern compiler developments. The design of some of the older optimization passes made it difficult to implement more advanced transformations and to make improvements at a faster pace. As the new framework was intended to be the basis of many future optimization efforts, a core design objective was to make it easier to implement, test and measure new optimizations.

Some of the main goals of the project:

• Improving the code quality for both scalar and vector code

There are many cases where both performance and code size can be improved, sometimes quite substantially. The framework attempts to solve several deficiencies of the old optimizer:

• The old expression optimizer has a small set of known transformations and a limited view of the function – this prevents discovering all the expressions that could be optimized.
• Many small optimizations based on identifying patterns – known as peephole optimizations – are either missing or implemented only for certain target architectures.
• Vector code – either from intrinsics or generated by the auto-vectorizer – can be optimized better.

The new optimizer takes advantage of the Static Single Assignment form, which allows handling more complex expressions, that potentially span the entire function. Another advantage of the SSA form is that it makes it possible to write simpler and more efficient algorithms, eliminating the need of using more complicated and slower techniques such as data-flow analysis.

Peephole optimizations can now be implemented in a target-independent way, using a pattern matching system that is very fast (based on template meta-programming) and which requires little code to be written. This allowed adding a large number of patterns in a fraction of the time it takes to add using the usual way of identifying patterns.

The same pattern matching mechanism can be used for vector operations, making it now possible to optimize expressions using both integer and float vector operations as easily as expressions with scalar operations. Note that this feature is not yet complete and enabled.

• Designing a framework that allows easy development, with less potential for mistakes

Being able to quickly prototype ideas and move to a reliable implementation is one of the main advantages of the new framework. It includes various helpers for easier manipulation of the SSA form, pattern matching of expressions, building new expressions and doing safety checks in the presence of pointer aliasing and exception handling.

• Performing better static analysis of the code

The new optimizer also adds new static analysis modules, including those that can identify when a value is Boolean (exactly either 0 or 1), when a value is always positive, and when a value cannot be zero. It also has a powerful module that can estimate known one/zero bits of a value, and the ranges a value could fall in. The results are either used as preconditions for certain optimizations, to eliminate some useless operations completely or to transform operations into a form that can be optimized better.

• Strong emphasis on testing and correctness

Given the large scope of the project, ensuring and maintaining correctness was a top priority. This was achieved by using formal verification, testing with randomly-generated programs (fuzz testing) and popular programs and libraries such as Chrome, Firefox, CoreCLR and Chakra. See the Testing approach section below for more details.

Examples of implemented optimizations

The following is an example that illustrates just a few of the many new transformations the new optimizer implements. This sort of code is often found in codecs:

int test(int a) {
    return a % 2 != 0 ? 4 : 2;
}

?test@@YAHH@Z PROC
and   ecx, -2147483647
jge   SHORT $LN3@test
dec   ecx
or    ecx, -2
inc   ecx
$LN3@test:
test  ecx, ecx
mov   eax, 2
mov   edx, 4
cmovne eax, edx
ret   0

?test@@YAHH@Z PROC
and   ecx, 1
lea   eax, DWORD PTR [rcx*2+2]
ret   0

The execution time with the old optimizer is approximately 5 cycles in the best case (this assumes out-of-order execution and perfect branch prediction) and at least 10 cycles in the worst case. With the new optimizer, execution time is always 2 cycles. Obviously, there are also important savings in code size.

Very interesting results can be achieved by combining multiple smaller transformations. In this case, there are two patterns applied to produce the final result:

• a % 2 == 0 -> a & 1 == 0
  Since the remainder is esed to zero, the sign of a does not affect the compare result and the remainder can be replaced by AND.
• a<bool> ? C1 : C2 -> C2 + a*(C1-C2)
  A ternary question operation selecting between two constants. The first requirement is that the condition value is Boolean, which the static analysis package can determine. The second is that C1-C2 is a power of two, so that a shift or LEA is generated instead of a multiplication.

Let’s see a few more examples of interesting optimizations and patterns that are implemented. Focus was put especially on operations that were previously not optimized very well, such as comparisons, conversions, divisions, question and control-flow dependent expressions (PHI operations in SSA form). Although some examples might seem unlikely to be written like that in the source code, they do appear quite often after inlining and other transformations.

• Improved optimization of arithmetic expressions, including scalar float operations

The SSA form exposes larger expressions, which can span the entire function – this allows discovering more optimization opportunities, especially when combined with expression reassociation. There are also dozens of new patterns added, such as the following ones:

(a / C1) / C2 -> a / (C1 * C2)
(a * C1) / C2 -> a * (C1 / C2)
a / (x ? C1 : C2) -> a >> (x ? log2(C1), log2(C2)) // C1 and C2 must be power of two constants

Most new float optimizations are enabled only under -fp:fast, but some of them are valid under the default -fp:precise.
More information about the optimizations allowed under different floating point models is available in the documentation:
Microsoft Visual C++ Floating-Point Optimization

• Optimizing control-flow dependent expressions

I mentioned above that the SSA format simplifies handling larger, more complex expressions. One advantage is that it makes it easier to reason about variables that are either redefined, or defined with different values based on the path taken in the function. As its name implies, SSA solves this by creating a different version of the variable each time it is redefined; if there are points in the function where a variable has more than one possible value, a pseudo-operation known as PHI is inserted, merging all values.

Although building the SSA format is quite complicated, the example below should be simple enough to get a good intuition about SSA and the role of the PHI operations:

int test(int a, int b) {
    int x, y, z;

    if(a > 3) {
        x = 4;
        y = 1;
        z = b & 0xFF00;
    }
    else {
        x = 9;
        y = 2;
        z = b << 8;
    }

    int p = (x * y) * 4;
    int q = z & 0xF;
    return p >= 16 && q == 0;
}

int test(int a1, int b1) {
    int x0, y0, z0; // undefined

    if(a1 > 3) {
        x1 = 4;
        y1 = 1;
        z1 = b1 & 0xFF00;
    }
    else {
        x2 = 9;
        y2 = 2;
        z2 = b1 << 8;
    }
    x3 = PHI(x1, x2)
    y3 = PHI(y1, y2)
    z3 = PHI(z1, z2)

    int p1 = (x3 * y3) * 4;
    int q1 = z3 & 0xF;
    return p1 >= 16 && q1 == 0;
}

As it can be seen on the right side, each variable is renamed to multiple versions (indicated by the number suffix). After the if-then-else statement, all three variables can have two different values, depending on the runtime result of a > 3, making it necessary to insert PHI operations.

The new optimizer is able to take advantage of the PHI operations and turn the entire function into the equivalent of return 1, all other code being removed by Dead Code Elimination. That’s 1 instruction compared to the 18 that were generated before on x64.
For p1 >= 16 it computes every possible value and compares it with 16, which is the minimum possible value. For q1 == 0 it checks if the low bits are known to be zero in both z1 and z2.

The old expression optimizer is not able to reason about the larger expressions that involve these PHI operations – this causes it to miss many optimization opportunities, like the ones exemplified above. In the new optimizer, every operation and static analysis supports PHI. A few more examples:

(phi 3, 5) + 2 -> phi 5, 7     // constant-fold by pushing operand inside a PHI
(phi b+3, b+5) - b -> phi 3, 5 // eliminate operation by pushing operand inside a PHI
phi a+x, b+x -> (phi a, b) + x // extract a common operand from a PHI
(phi 1,2) + 3 < (phi 3,4) + 5 -> true                 // fold compare by testing all combinations
(phi 1,2) * (phi 2,3) > (phi 6,7) * phi(2,3) -> false // similar to above example
(phi 1,0) * 5 > (phi 1,2) -> undecidable              // 0 * 5 < (phi 1,2)

The following is an interesting case found in Mozilla Firefox. A Boolean expression, spanning an if-then-else statement, is used in a negated form if(!expr). The new algorithm that tries to cancel an inverted Boolean operation by inverting every subexpression did the following transformation, eliminating the inversion:

(phi 0, (x ? 1 : 0)) ^ 1 -> phi 1, (x ? 0 : 1)

• Better conditional move generation

Converting branches to CMOV produces more compact code that usually executes faster. The late CMOV generation phase is augmented by generating question operations during the new optimizer. In doing so, already-existing transformations can be applied, simplifying things even further. In the following examples, the left-hand side is a newly-detected CMOV pattern, and the right-hand side is the code after a transformation is applied:

a < 0 ? 1 : 0 ->  a >> 31           // logical shift
a < 0 ? 4 : 0 -> (a >> 31) & 4      // arithmetic shift
a<bool> != b<bool> ? 1 : 0 -> a ^ b // a, b must be Boolean values

CMOV performance can sometimes be hard to estimate, especially on modern CPUs with good branch prediction. To help in cases where a branch would be faster, when profile information is available, the CMOV is not generated if the branch is highly predictable (heavily biased as either taken or not-taken).

• Improved optimization of compare operations

Comparisons are the operations with the most improvements. Since reducing the number of branches benefits both code size and performance, the focus was mainly on branch folding (eliminating a branch by proving that it is either taken or not-taken). Besides the usual tests for comparing constants, static analysis is used to estimate value ranges and known one/zero bits, making it possible to handle more complicated cases. Among the dozens of transformations that simplify comparisons, the following one is an example that reduces execution time substantially:

a / 12 == 15 -> a in range [180, 192) -> (a – 180) < 12 // unsigned compare

A division (20+ cycles) is replaced by a simple range check (2 cycles). Even when the “divide by constant” optimization is applied, it is still a few times slower than the range check.

• Bit Estimator

This is a powerful static analysis that can be used to extract more compile-time information about values. Some of the provided features:

• Estimating bits known to be one or zero
• Proving that a value is not zero
• Estimating the minimum and maximum value
• Estimating value ranges
• Improved overflow checks for addition and subtraction

Below is a simple example showing how the one/zero bits can be computed at at compile time, even when nothing is known about the initial values (parameter a in the example below):

int test(unsigned char a) {
    short b = a;    // b: 00000000________, a: ________ 
    b <<= 4;        // b: 0000________0000
    b |= 3;         // b: 0000________0011
    return b != 0;  // -> return true  
}

Some of the places where these features are currently used:

• Converting signed instructions to unsigned: produces smaller code for division/remainder with constant, allows folding constants into LEA instructions, etc.
• Folding comparisons and branches: comparisons are folded using both known bit and value range information. For example, given a == b, if a is known to have a bit set at a position where it is definitely not set in b, the two values cannot be equal. This can be applied to other conditions such as less-than by checking the sign bit. When using value ranges, every range of a is compared with every range of b.
• Improved overflow checks: optimizing a + C1 < C2 into a < C2 – C1 is not valid, since a + C1 might overflow, giving a different result. Using the known bits or value ranges, it can be proven that the addition does not overflow. In practice, this usually happens when a is a zero-extension from a smaller type.
• Discovering Boolean and positive values: used as pre-conditions for various optimizations, such as the ones applied on question operations. Another example is eliminating an ABS intrinsic if the value is already positive.
• Removing redundant AND/OR instructions, eliding useless conversions:

a % C -> 0  if C is a power of two and the low bits in a are zero (a is a multiple of C)
a & C -> 0  if all bits that are one in C are known to be zero in a
a | C -> a  if all bits that are one in C are known to be one in a

• Improved Common Subexpression Elimination

Common Subexpression Elimination is an optimization that eliminates redundant operations by replacing them with the result of previous ones that compute the same value – this happens much more often than one may expect. The existing algorithm is augmented with one based on Global Value Numbering, which increases the number of expressions that are found to be equivalent. Although this is a quite simple initial implementation that will be made more powerful, it shows significant improvements for both code size and performance.

Eliminating redundant operations before doing the expression optimization also exposes more opportunities.
For example, (a + b) – c -> a if b is found to be equivalent to c.

• Taking advantage of signed integer overflow being undefined

Historically, Visual C++ did not take advantage of the fact that the C and C++ standards consider the result of overflowing signed operations undefined. Other compilers are very aggressive in this regard, which motivated the decision to implement some patterns which take advantage of undefined integer overflow behavior. We implemented the ones we thought were safe and didn’t impose any unnecessary security risks in generated code.

A new undocumented compiler flag has been added to disable these optimizations, in case an application that is not standard-conformant fails: -d2SSAOptimizerUndefinedIntOverflow-. Due to security concerns, we have seen cases where these patterns should not be optimized, even though following the C and C++ standards allows us to by making the potential addition overflow undefined:

a + Constant  > a -> true   // Constant > 0
a + Constant <= a -> false  // Constant > 0

These two tests (and the similar ones with subtraction) are frequently used to check for overflow in places such as file readers and memory allocators. While the use is non-conformant with the standard and a well-known issue, enabling these transformations could potentially break the security of those applications.

Impact on code size

For most applications code size is reduced, but it can also increase due to interactions with other optimizations. For example, a smaller function is more likely to be inlined into multiple places, resulting in a size increase overall.

Below are some code size results from compiling several large applications on x64:

The following table lists the number of instructions, split by category, for the Windows Kernel built for x64 with link-time code generation and profile information. It can be seen that the number of more expensive instructions, such as branches, divisions and multiplications, is reduced. The increase in CMOV and SETcc is a result of more branches being converted to conditional code.

Impact on compiler throughput

For all these improvements, compile time remains mostly the same, with about +/- 2% difference, depending on the application being compiled. For example, Google Chrome shows a compile time slowdown of 1.7%, while compiling the Windows Kernel shows a 2.6% speed-up. The speed-up can be explained by having less code go through the old, slower optimization passes.

Testing approach

Based on previous experience and the scope of the project, it was clear from the start that extensive testing needs to take a central role to ensure correctness. Several testing approaches were used, some to prevent mistakes in the first place, others to catch implementation problems:

• Preventing implementation bugs by formally verifying the patterns

Most patterns are quite simple, such as x & 0 => 0. But there are also patterns that requires validation that is not always very obvious, leaving place for mistakes. The most common validation bugs are:

• Failing to check for input preconditions, such as requiring positive numbers, powers of two, numbers with the N top bits 0, etc
• Failing to differentiate between signed and unsigned operations. This is especially dangerous for instructions such as CMP, DIV/REM and SHR.

Alive, a tool by Nuno Lopes from Microsoft Research, is a formal verification tool that was used to ensure the patterns and preconditions are correct before implementing them. It uses a language similar to LLVM IR and the Z3 theorem prover to verify if an input pattern is equivalent to the output pattern – if not, it prints a counterexample. Alive has already been used by the LLVM community with great success to discover many bugs. More details about Alive can be found on John Regehr’s blog: ALIVe: Automatic LLVM InstCombine Verifier.

• Covering and testing as many patterns as possible using random tests

Csmith is a random C program generator that has been used to discover a large number of bugs in various compilers. More than 15 million programs generated using CSmith have been tested, revealing several bugs in the new optimizer, plus bugs in other optimizer components. Very helpful in dealing with the huge failing tests was C-Reduce: is was able to reduce 200KB tests to tests of 2-3KB in size, making it much easier to spot the place with the bug.

• Testing every three-instruction expression

Opt-fuzz, a tool by John Regehr from University of Utah, is able to generate every small integer expression with N instructions and a limited number of possible constants as LLVM IR. The Clang/C2 project made it possible to test all 250+ million tests generated for three-instruction expressions, which revealed several subtle bugs.

• Using instrumentation and runtime checks

Complex components, such as the Bit Estimator and Value Numbering, were tested by instrumenting the compiled code with calls to a runtime library that verifies if the compile-time, static analysis results are actually valid. For example, in the case of the Bit Estimator, it would verify that the bits that were estimated to be always zero are zero at runtime. In the case of Value Numbering, it would ensure that two instructions that were assigned the same value number have the same value at runtime.

• Testing with popular open-source projects

Exposing the compiler to more real-world code proved to be an effective way to find more bugs. This includes building and testing Google Chrome, Mozilla Firefox, CoreCLR and Chakra.

Future improvements

As I mentioned at the start of the blog post, the framework is designed to be the place where many of the future optimizer features will be implemented. Below are some of the optimizations that are very likely to be part of the next major Visual Studio release – it does not include any of the longer-term projects that are planned:

• Complete and enable the optimization of vector operations
• Better optimization of Boolean expressions in C++ code
• Removal of operation with no effect on the expression result
• Merging similar branches
• Several Bit Estimator improvements

Closing remarks

Please try building and testing your applications with the new optimizer and report any problems that you might find. We are looking forward for your suggestions and opinions in the comment section. Let us know if you have examples of cases that could be optimized better and are not yet handled.

We are glad to finally be able to share this exciting new work with you! This marks the start of many optimizer improvements that will be added in the future releases of the compiler – we will keep you posted.

Thanks,
Gratian Lup
Visual C++ Optimizer team

Today is an exciting day for all of us on the C++ team here at Microsoft! We love that we offer the great development experience C and C++ developers enjoy in Visual Studio on Windows, but at the same time we realize that some of you, for your own reasons, have chosen Linux or OS/X as your primary development platform, so you cannot utilize Visual Studio for your development needs. Today we are announcing a Preview of a product for your C/C++ editing and debugging needs on Linux and OS/X: the C/C++ extension to Visual Studio Code.

For those of you who are not aware of Visual Studio Code, Visual Studio Code is a new choice of tool in the Visual Studio family of products which combines the simplicity of a code editor with what developers need for their code-edit-debug cycle. The current Visual Studio Code experience only provides basic syntax highlighting support via the C/C++ text made bundle, this preview version of the C/C++ extension introduces a better language service experience with support for code-navigation and the ability to debug C/C++ applications but given this is a preview release there are a few caveats to this experience!

In the rest of this post I will assume that you have downloaded and configured Visual Studio Code, and also the preview of the C/C++ extension that we are announcing here.  I will walk you through the editing experience, the debugging experience, and options for compiling/building your code. I will close by sharing some useful links on how to report issues, make requests, and in general how to give us feedback on our current plans.

Using the C/C++ code-editing aids in Visual Studio Code

As soon as a folder containing C/C++ sources is loaded into Visual Studio Code the language service engine kicks in and the tag-parser starts parsing the source directory generating an offline database to store symbol information (browse.VC.db file). Look for the flaming red platform icon (Win32 in the figure below) which denotes parsing in progress.

Once the symbol data base population is complete you are ready to try out the preview experience of the language services portion of this extension. The preview experience for the language service experience currently introduces support for code navigation through the following feature set.

Navigate to a particular symbol within the same source file (Ctrl + P, @Symbol Name)

Navigate to a particular symbol across source files (Ctrl + P, #Symbol Name)

Go to definition (F12)

Peek definition (Alt + F12)

Cntrl + Hover

Given that this is indeed a preview experience there are a few caveats. While Go to definition and Peek definition will work for most part it’s currently not wired up to work for locals. This is primarily because the tag-parser currently does not parse function bodies. Also given there is currently no semantic analysis that is performed, Go to definition and Peek definition as  only some-what accurate as they are based upon text parsing and matching of symbols. We are working hard to make this happen.

While the current language service experience is designed to provide you value out-of-the-box, one can further improve the experience by  providing a little more information about include paths not in your working directory opened in Visual Studio Code. In the future we will use the same mechanism to ask for more details to drive other language service features such as Auto-Complete.

As you traverse through your source code you will notice some headers are squiggled. The reason why these headers are squiggled is because we were not able to find them in the current source or sub source folders opened in Visual Studio Code. Hovering over these squiggles a light bulb action will appear which will allow you to specify the path on disk for these headers in a properties file known as the ‘c_cpp_properties.json’ file as shown in the figure below.

Adding your include directories to the “includePath” property in this file for the specific configuration you are interested in will help drive a more complete and accurate language service experience.

Debugging your C/C++ application in Visual Studio Code

This extension also introduces great support for debugging your C++ program with Visual Studio Code. You’ll be able to use all of the standard debugging capabilities that you’re familiar with, including setting and hitting breakpoints, stepping, inspecting variables, and viewing the call stack. Beyond that, you’ll also able to take advantage of some advanced debugging capabilities, including function breakpoints, expression evaluation, conditional breakpoints, and core dump debugging.

The debugging experience currently only works out-of-the-box for Linux – Ubuntu 14.04 (x64). We are working on OS X support as well, the current experience requires manual installation steps and has some limitations. Debugging on windows with VSCode for C/C++ code is currently not supported.

Getting set up

Before you can get started debugging C++ code in Visual Studio Code, you’ll need to set a few things up. Navigate to the Debug View by clicking on the debug icon on far left toolbar. Hit the “Settings” gear icon in the debug pane and select “C++ Launch (GDB).” This will bring up the launch.json file.

The launch.json file defines a set of configurations that tell the debugger how to interact with your built application. We include two configurations by default—one which shows the properties necessary for launching the application from VS Code, and the other which shows the properties necessary for attaching to an already running process. Hovering over a property name will show a tooltip that describes the property and possible values, but minimally you will need to update the “program” property to have the program name and path. You can learn more about the properties in the launch.json file and how to use them by reading the VS Code debugging documentation.

Once your launch.json file is properly configured, you’re ready to debug a C++ program. Note that VS Code will not build your program (but simply debug the built program) unless you also create a task.json file and set it to the preLaunchTask property in the launch.json file.

Function Breakpoints

Function breakpoints enable you to break execution at the beginning of a function rather than on a particular line of code. To set a function breakpoint in VS Code, right click in the breakpoints pane and click “Add Function Breakpoint,” then type the name of the function on which you’d like to break.

Expression Evaluation

Debugging C++ code often requires more than simply viewing the value of variables at a breakpoint. The C++ extension for VS Code has support for evaluating expressions in several spaces. You can type an expression into the Watch pane, and it will be evaluated when a breakpoint is hit. Note that this has side effects—an expression that modifies the value of a variable will modify that value for the duration of program execution. If you’d like to view the value of an expression that is a part of your code, you can hover over any expression in the editor while stopped at a breakpoint and the data tip will show the evaluated expression. If you only want to evaluate an expression once (rather than having it in the Watch pane), you can simply type the expression in the Debug Console.

Conditional Breakpoints

Right clicking on a breakpoint and selecting “Edit breakpoint” will open a peak window in your editor. Type a condition (eg. “i > 15”) and that breakpoint will only activate and break execution when that condition evaluates to true. Conditional breakpoints are indicated by a breakpoint symbol that has the black equals sign. Hovering over a conditional breakpoint will show its value.

Core Dump Debugging

The extension also offers the ability to debug using a memory dump. To do this, add the “coreDumpPath” property to the C++ Launch configuration in your launch.json file and set it to the path to your core dump. This will even work for multi-threaded programs and x86 programs being debugged on a x64 machine.

GDB and MI commands

You can also use the debug console with the “-exec” command to execute GDB commands directly (be careful though—executing GDB commands directly in the debug console is untested and may crash VS Code in some cases). A full introduction to debugging in VS Code is available here.

A quick demo demonstrating  the C/C++ experience:

Let us know what you think!

This particular release of the C/C++ extension for Visual Studio Code is a start and we’ll need your help to make this a full experience. If you’d like to help us build the best C/C++ experience on any platform, you can join our Cross-Platform C++ Insiders group where you’ll be able to talk directly to the product team and influence our investment in this area. We also recognize that there are some immediate asks you’re likely to have, so please go ahead and add them to  Visual Studio Code user-voice and we would love your help in prioritizing them just right.

Thank you for reading to the end, I look forward to seeing the bugs you report, and the requests you want us to consider. If you have any questions or comments that don’t fit a bug or a feature request, please drop me a comment below – our team is monitoring this blog comments and of-course don’t forget to go download the C/C++ extension for VS Code.

Would like to thank all who have tried out the C/C++ extension in Visual Studio Code and have already provided rich feedback on their experiences, filed issues with us. Pairing with the Visual Studio Code 1.0 announcement we are also updating the C/C++ extension today in VSCode with the following improvements based upon the feedback that we have heard so far:

Code Editing

Debugging

Update your extension now!

If you already using the C/C++ extension, you can update your extension easily by using the ext update dropdown. This will display any available updates for your currently installed extensions. Simply click the Update Extension button in the lower right for the outdated extension and the update will be installed and you’ll be prompted to restart VS Code.

Wrap up

For more information about the overall VSCode C/C++ experience you can refer to our original blog-post and documentation which has been updated w.r.t. changes. Please help us by continuing to file issues at our Github account and keep trying out this experience and if you would like to shape the future of this extension please join our Cross-Platform C++ Insiders group where you can speak with us directly and help us on this venture.

Today is an exciting day for all of us on the C++ team here at Microsoft! We love that we offer the great development experience C and C++ developers enjoy in Visual Studio on Windows, but at the same time we realize that some of you, for your own reasons, have chosen Linux or OS/X as your primary development platform, so you cannot utilize Visual Studio for your development needs. Today we are announcing a Preview of a product for your C/C++ editing and debugging needs on Linux and OS/X: the C/C++ extension to Visual Studio Code.

For those of you who are not aware of Visual Studio Code, Visual Studio Code is a new choice of tool in the Visual Studio family of products which combines the simplicity of a code editor with what developers need for their code-edit-debug cycle. The current Visual Studio Code experience only provides basic syntax highlighting support via the C/C++ text made bundle, this preview version of the C/C++ extension introduces a better language service experience with support for code-navigation and the ability to debug C/C++ applications but given this is a preview release there are a few caveats to this experience!

In the rest of this post I will assume that you have downloaded and configured Visual Studio Code, and also the preview of the C/C++ extension that we are announcing here.  I will walk you through the editing experience, the debugging experience, and options for compiling/building your code. I will close by sharing some useful links on how to report issues, make requests, and in general how to give us feedback on our current plans.

Using the C/C++ code-editing aids in Visual Studio Code

As soon as a folder containing C/C++ sources is loaded into Visual Studio Code the language service engine kicks in and the tag-parser starts parsing the source directory generating an offline database to store symbol information (browse.VC.db file). Look for the flaming red platform icon (Win32 in the figure below) which denotes parsing in progress.

Once the symbol data base population is complete you are ready to try out the preview experience of the language services portion of this extension. The preview experience for the language service experience currently introduces support for code navigation through the following feature set.

Navigate to a particular symbol within the same source file (Ctrl + P, @Symbol Name)

Navigate to a particular symbol across source files (Ctrl + P, #Symbol Name)

Go to definition (F12)

Peek definition (Alt + F12)

Cntrl + Hover

Given that this is indeed a preview experience there are a few caveats. While Go to definition and Peek definition will work for most part it’s currently not wired up to work for locals. This is primarily because the tag-parser currently does not parse function bodies. Also given there is currently no semantic analysis that is performed, Go to definition and Peek definition as  only some-what accurate as they are based upon text parsing and matching of symbols. We are working hard to make this happen.

While the current language service experience is designed to provide you value out-of-the-box, one can further improve the experience by  providing a little more information about include paths not in your working directory opened in Visual Studio Code. In the future we will use the same mechanism to ask for more details to drive other language service features such as Auto-Complete.

As you traverse through your source code you will notice some headers are squiggled. The reason why these headers are squiggled is because we were not able to find them in the current source or sub source folders opened in Visual Studio Code. Hovering over these squiggles a light bulb action will appear which will allow you to specify the path on disk for these headers in a properties file known as the ‘c_cpp_properties.json’ file as shown in the figure below.

Adding your include directories to the “includePath” property in this file for the specific configuration you are interested in will help drive a more complete and accurate language service experience.

Debugging your C/C++ application in Visual Studio Code

This extension also introduces great support for debugging your C++ program with Visual Studio Code. You’ll be able to use all of the standard debugging capabilities that you’re familiar with, including setting and hitting breakpoints, stepping, inspecting variables, and viewing the call stack. Beyond that, you’ll also able to take advantage of some advanced debugging capabilities, including function breakpoints, expression evaluation, conditional breakpoints, and core dump debugging.

The debugging experience currently only works out-of-the-box for Linux – Ubuntu 14.04 (x64). We are working on OS X support as well, the current experience requires manual installation steps and has some limitations. Debugging on windows with VSCode for C/C++ code is currently not supported.

Getting set up

Before you can get started debugging C++ code in Visual Studio Code, you’ll need to set a few things up. Navigate to the Debug View by clicking on the debug icon on far left toolbar. Hit the “Settings” gear icon in the debug pane and select “C++ Launch (GDB).” This will bring up the launch.json file.

The launch.json file defines a set of configurations that tell the debugger how to interact with your built application. We include two configurations by default—one which shows the properties necessary for launching the application from VS Code, and the other which shows the properties necessary for attaching to an already running process. Hovering over a property name will show a tooltip that describes the property and possible values, but minimally you will need to update the “program” property to have the program name and path. You can learn more about the properties in the launch.json file and how to use them by reading the VS Code debugging documentation.

Once your launch.json file is properly configured, you’re ready to debug a C++ program. Note that VS Code will not build your program (but simply debug the built program) unless you also create a task.json file and set it to the preLaunchTask property in the launch.json file.

Function Breakpoints

Function breakpoints enable you to break execution at the beginning of a function rather than on a particular line of code. To set a function breakpoint in VS Code, right click in the breakpoints pane and click “Add Function Breakpoint,” then type the name of the function on which you’d like to break.

Expression Evaluation

Debugging C++ code often requires more than simply viewing the value of variables at a breakpoint. The C++ extension for VS Code has support for evaluating expressions in several spaces. You can type an expression into the Watch pane, and it will be evaluated when a breakpoint is hit. Note that this has side effects—an expression that modifies the value of a variable will modify that value for the duration of program execution. If you’d like to view the value of an expression that is a part of your code, you can hover over any expression in the editor while stopped at a breakpoint and the data tip will show the evaluated expression. If you only want to evaluate an expression once (rather than having it in the Watch pane), you can simply type the expression in the Debug Console.

Conditional Breakpoints

Right clicking on a breakpoint and selecting “Edit breakpoint” will open a peak window in your editor. Type a condition (eg. “i > 15”) and that breakpoint will only activate and break execution when that condition evaluates to true. Conditional breakpoints are indicated by a breakpoint symbol that has the black equals sign. Hovering over a conditional breakpoint will show its value.

Core Dump Debugging

The extension also offers the ability to debug using a memory dump. To do this, add the “coreDumpPath” property to the C++ Launch configuration in your launch.json file and set it to the path to your core dump. This will even work for multi-threaded programs and x86 programs being debugged on a x64 machine.

GDB and MI commands

You can also use the debug console with the “-exec” command to execute GDB commands directly (be careful though—executing GDB commands directly in the debug console is untested and may crash VS Code in some cases). A full introduction to debugging in VS Code is available here.

A quick demo demonstrating  the C/C++ experience:

Let us know what you think!

This particular release of the C/C++ extension for Visual Studio Code is a start and we’ll need your help to make this a full experience. If you’d like to help us build the best C/C++ experience on any platform, you can join our Cross-Platform C++ Insiders group where you’ll be able to talk directly to the product team and influence our investment in this area. We also recognize that there are some immediate asks you’re likely to have, so please go ahead and add them to  Visual Studio Code user-voice and we would love your help in prioritizing them just right.

Thank you for reading to the end, I look forward to seeing the bugs you report, and the requests you want us to consider. If you have any questions or comments that don’t fit a bug or a feature request, please drop me a comment below – our team is monitoring this blog comments and of-course don’t forget to go download the C/C++ extension for VS Code.

Would like to thank all who have tried out the C/C++ extension in Visual Studio Code and have already provided rich feedback on their experiences, filed issues with us. Pairing with the Visual Studio Code 1.0 announcement we are also updating the C/C++ extension today in VSCode with the following improvements based upon the feedback that we have heard so far:

Code Editing

Debugging

Update your extension now!

If you already using the C/C++ extension, you can update your extension easily by using the ext update dropdown. This will display any available updates for your currently installed extensions. Simply click the Update Extension button in the lower right for the outdated extension and the update will be installed and you’ll be prompted to restart VS Code.

Wrap up

For more information about the overall VSCode C/C++ experience you can refer to our original blog-post and documentation which has been updated w.r.t. changes. Please help us by continuing to file issues at our Github account and keep trying out this experience and if you would like to shape the future of this extension please join our Cross-Platform C++ Insiders group where you can speak with us directly and help us on this venture.

Background

Visual Studio 2015 introduced the Diagnostic Tools window including the native memory profiler.  The native memory profiler collects Windows ETW events from the heap provider and analyzes them in order to determine the type and call stack of each allocation, as shown in this screenshot.  This tool will show all of the allocations made directly on the Windows NT heap, but allocations outside the Windows heap would not show any type information.

Reducing Allocation Overhead Using Custom Heaps

There are often times when minimizing the allocation overhead from the Windows heap is desirable.  One options is to use VirtualAlloc to grab a large amount of memory upfront and then manage blocks within that.  A common strategy in game development and other high performance applications is to use custom pool allocators, which allocate upfront a fixed-size block of memory upfront for a specific purpose, whether it be for a batch of sprites, or an entire game level.  This strategy avoids the constant instantiation overhead of the Windows heap by enabling performance boosting techniques when managing objects, such as keeping like objects in a pool to boost cache performance.  In the following example, we are creating a memory pool for allocating Foo objects called mPool:

Acquiring a new object is as easy as simple iterating the address space and casting each block to the appropriate type.  This avoids any additional overhead made by using a CRT/Windows allocator like new.

When using heap management optimizations like pools allocators, Windows ETW events cannot be used to track the allocations since allocations from a pool are not relying directly on the OS to create each object allocation.

Adding Support for Custom Heap Events

There are a few steps required to enable the memory profiler to show the type and call stack of each allocation made from a custom heap.

Determining the Type of Each Allocation

The Visual C++ v19.0 compiler (platform toolset v140) introduced support for describing a function as an allocator, as shown below for myMalloc.  Both the declaration and definition of the functions must be annotated as follows:

At each call to an allocator function, the address of the call site, the size of the call instruction, and the typeid of the new object are emitted into a new S_HEAPALLOCSITE symbol inside the PDB.  When the Windows heap code emits an ETW event with a call stack for an allocation, the memory tool walks the call stack looking for a return address matching an S_HEAPALLOCSITE symbol.  The typeid in the symbol determines the runtime type of the allocation. Allocators from both the Windows SDK and CRT have been annotated with __declspec(allocator), so calls into these will provide the type information and call stack to the Visual Studio memory profiler.

When calling into a custom allocator function, the return needs to be casted as follows to ensure the type information will be available in the memory profiler:

 Creating a Heap Tracker

In order to enable tracking allocations outside the Windows heap using the Visual Studio memory profiler, we have created a custom heap event API to provide the same allocation information as ETW events provide for the Windows heap.   This library ships inside the Visual Studio “15” Preview 2 which can be downloaded You must link to the static library which is found in the C:\Program Files (x86)\Microsoft Visual Studio 15.0\VC\Lib\VSCustomNativeHeapEtwProvider.lib in order to use the API.

After linking to the static library, include the required header so you can create a VSHeapTracker::CHeapTracker object inside the header for your memory pool interface.  In order to access this namespace, you must include the header:

Inside your application code, you can then input a name for the heap when you create the heap tracker object.  This name will be exposed in the Visual Studio heap snapshot window during a memory profiling session:

Creating Heap Events

The API in the header filer declares multiple types of custom ETW heap events that can be fired for allocate, deallocate, and reallocate.  The AllocateEvent declaration is shown below:

To make use of this event, simply call the method from your heap tracker object inside your custom “allocate” function that has been decorated with __declspec(allocator), like we did with myMalloc:

In case you are not yet using the Preview 2 bits and would like to examine the full heap event interface, consult the attached VSCustomNativeHeapEtwProvider.h file at the end of the post.

Viewing Custom Heaps in the Memory Profiler

Since the memory profiler in Visual Studio 2015 worked only with the Windows NT heap, we had to add a new UI control in Visual Studio “15” Preview to enable selecting other custom heaps.  When a heap snapshot is taken with a custom heap registered, the heaps will be listed as named by the user in the heap dropdown at the upper right:

The NT (Windows) heap is selected by default and lists the allocations we made on this heap, including the heap tracker and the memory pool itself we created (mPool) represented by the Foo[] array.

Since we added the heap tracker named FooHeap, this will appear in the heap dropdown and show the subsequent allocations contained in the memory pool when selected.  In this case nine Foo objects were allocated in the pool and each has been tracked by the memory profiler.  Just as with previous releases, the memory profiler allowing diffing snapshots can be diffed using the “Compare to” dropdown which can help reveal leaks by showing the objects still in memory.

Note that the allocations sourced from a custom heap will not show up in the snapshot summary table since this information is populated by information directly from the Windows heap.  The count will only show up in the snapshot itself when the source heap is selected.

Try it out!

You can download Visual Studio with this new capability and try the memory profiler on you own custom heap allocators.  Here is a link to the VSCustomNativeHeapEtwProvider header file if you would like to examine the interface but do not yet have Preview 2 installed.  Here is a link to the code for the memory pool allocator used in this blog post.

We would like to thank all of you who have tried out the C/C++ extension in Visual Studio Code and have already provided
rich feedback on your experiences and filed issues and requests with us. We are working hard on incorporating your feedback
into the product. Continuing with our effort to make Visual Studio Code as the editor tool of choice for C++ developers with
this update of the C/C++ extension, we are introducing the following features:

• Code formatting with clang-format
• Fuzzy Auto-Complete for C/C++ code
• Debugging on Windows for Cygwin/MinGW applications
• Console application debugging with GDB on the Mac

Now let’s dive into each one of these in more detail.

Code formatting with clang-format

You can now format your C/C++ code with clang-format from inside Visual Studio Code. Currently clang-format needs to be
installed manually and the path for clang-format needs to be added to user settings in Visual Studio Code as shown in the figure below.

By default, the clang-format style is set to ‘file’ which means it looks for a pre-existing. clang-format file, if the. clang-format file is found it
applies formatting settings specified in the file. If the. clang-format file is not found the default fallback-style specified in the c_cpp_properties.json file is used. The default fall back style is set to ‘LLVM’ today.

This clang-format behavior is controlled via the settings file ‘c_cpp_properties.json’ file which can be loaded and edited by executing the following command from the command palette.

Fuzzy Auto-Complete for C/C++ code

This update of the C/C++ extension in Visual Studio Code also introduces a preview version of a fuzzy Auto-Complete for C/C++ code. It’s based on an enhanced tag-parser approach, in other words no semantic analysis, so while it is not quite accurate it will still provide you more than what single-file intellisense provides you today. Additionally, this fuzzy intellisense approach will work pretty well for straight up C code so try it out and let us know what you think!

Debugging on Windows for Cygwin/MinGW applications

Another feature  we are adding as a part of this update is the ability for developers to be able to debug their C/C++ Cygwin/MinGW applications using Visual Studio Code. Users can choose to attach to or launch the application to debug directly. In order to use cygwin or MinGW, the debugger path must be set manually in the launch configuration (launch.json). This is done via the ‘miDebuggerPath’ property, as the following figure shows:

Console application debugging with GDB on the Mac

In our previous release, we did not have the capability to debug console applications on the Mac using GDB. This has been added to this release. There are some known issues still, due to limitations with GDB. Please see the readme for more information.

Update your extension now!

If you are already using the C/C++ extension, you can update your extension easily by using the ext update dropdown. This will display any available updates for your currently installed extensions. To install the update, simply click the Update Extension button in the lower right for the outdated extension. You’ll be prompted to restart VS Code.

Please refer to the original blog post for links to documentation and for more information about the overall experience of Visual Studio Code C/C++. Please help us by continuing to file issues at our Github page and keep trying out this experience and if you would like to shape the future of this extension please join our Cross-Platform C++ Insiders group, where you can speak with us directly and help make this product the best for your needs. 

The Universal Windows Platform (UWP) introduced many async APIs; there are now almost 1700 of them. In fact, the team switched every API that could take 50ms or more to complete to async mode.

Coding with the async pattern is not an easy task, especially in C++ where you have to create a ppl task and use a continuation (.then) with some lambdas. In fact, in many cases writing the code itself is not so hard, but the readability is not good.

C++ Coroutines can simplify your async code, and make the code easy to understand, write, and maintain. But rather than give you a 1000-word description, let’s look at an example:

In this code we try to open an image, using PickSingleFileAsync and OpenAsync:

void AsyncDemoForBuild::MainPage::PickImageClick(Platform::Object^ sender,
  Windows::UI::Xaml::RoutedEventArgs^ e)
{
  using namespace Windows::UI::Xaml::Media::Imaging;
  using namespace Windows::Storage::Pickers;
  using namespace concurrency;

  auto picker = ref new FileOpenPicker();
  picker->FileTypeFilter->Append(L".jpg");
  picker->SuggestedStartLocation = PickerLocationId::PicturesLibrary;

  create_task(picker->PickSingleFileAsync()).then([this]
    (Windows::Storage::StorageFile^ file)
  {
    if (nullptr == file)
      return;

    create_task(file->OpenReadAsync()).then([this]
      (Windows::Storage::Streams::IRandomAccessStreamWithContentType^ stream)
    {
      auto bitmap = ref new BitmapImage();
      bitmap->SetSource(stream);
      theImage->Source = bitmap;
      OutputDebugString(L"1. End of OpenReadAsync lambda.\r\n");
    });

    OutputDebugString(L"2. End of PickSingleFileAysnc lambda.\r\n");
  });

  OutputDebugString(L"3. End of function.\r\n");

}

The code introduces complexity because of the async model, but if it was synchronous, it would look a lot nicer:

//Pseudo Code

Void ShowImage()

{

auto picker = ref new FileOpenPicker();

picker->FileTypeFilter->Append(L”.jpg”);

picker->SuggestedStartLocation = PickerLocationId::PicturesLibrary;

auto file = picker->PickSingleFile();

auto stream = file->OpenRead();

auto bitmap = ref new BitmapImage();

bitmap->SetSource(stream);

theImage->Source = bitmap;

}

With Coroutines, we can use co_await in C++, but we still need to be in a task, so the code could be written like this:

#include <experimental\resumable>

#include <pplawait.h>

using namespace Platform;

task<void> AsyncDemoForBuild::MainPage::PickAnImage()
{
    auto picker = ref new FileOpenPicker();
    picker->FileTypeFilter->Append(L".jpg");
    picker->SuggestedStartLocation = PickerLocationId::PicturesLibrary;

    auto file = co_await picker->PickSingleFileAsync();
    if (nullptr == file)
        return;

    auto stream = co_await file->OpenReadAsync();

    auto bitmap = ref new BitmapImage();
    bitmap->SetSource(stream);
    theImage->Source = bitmap;
    OutputDebugString(L"1. End of OpenReadAsync lambda.\r\n");
}

And we could call it this way:

void AsyncDemoForBuild::MainPage::PickImageClick(Platform::Object^ sender,  Windows::UI::Xaml::RoutedEventArgs^ e)
{
    PickAnImage();
}

As you can see in this sample, UWP C++ code can be made much simpler by using co_await; almost as simple as the synchronous form. We see also that co_await can be used with C++/Cx code, meaning you can use ‘^’ references without any ambiguities.

Of course, the code has to be compiled using the /await option in the command line:

It’s important to note that in Visual Studio 2015, Update2 you can also use the /SDL option.

This form of Coroutine (co_await) is the easiest way to use Coroutines. However, Coroutines in C++ can do much more. For example, you can:

· Define new awaitables to customize await for your environment using existing coroutine types.

· Define new coroutine types.

Have a look at this post about customized awaiters. We’ll have more posts to come on other async coding subjects.

Note that Coroutines are not yet part of the C++ standard, but are only found in a TS (Technical Specification) and needs to be seen as experimental (more info here). However, since we removed some compatibility friction with the /RTC and /SDL options in VS2015 Update2, we consider Coroutines ready for production. Please let us know about your experiments, your questions, and any issues you find.

We recorded a video about this for //build 2016.

Would like to thank all who have tried out the C/C++ extension in Visual Studio Code and have already provided rich feedback on their experiences, filed issues with us. Pairing with the Visual Studio Code 1.0 announcement we are also updating the C/C++ extension today in VSCode with the following improvements based upon the feedback that we have heard so far:

Code Editing

Debugging

Update your extension now!

If you already using the C/C++ extension, you can update your extension easily by using the ext update dropdown. This will display any available updates for your currently installed extensions. Simply click the Update Extension button in the lower right for the outdated extension and the update will be installed and you’ll be prompted to restart VS Code.

Wrap up

For more information about the overall VSCode C/C++ experience you can refer to our original blog-post and documentation which has been updated w.r.t. changes. Please help us by continuing to file issues at our Github account and keep trying out this experience and if you would like to shape the future of this extension please join our Cross-Platform C++ Insiders group where you can speak with us directly and help us on this venture.

This blog post written by Dave Bartolomeo, Yuriy Solodkyy, and Andrew Pardoe

We have just released our fifth out-of-band update of Clang/C2 toolset. As always, this release has been driven by your feedback. While we’ve heard a lot of feature requests the one’s we’ve heard most frequently are that you want Clang 3.8 and you want x64-hosted compilers. We’re happy to say that we’re shipping both Clang 3.8 and x64-hosted compilers in the May 2016 release.

Clang 3.8 is the latest official release of Clang. Moving to Clang 3.8 brings in roughly six months of features and bug fixes from the Clang community. We’ve also added x64-hosted versions of the Clang/C2 compiler toolset. This enables you to compile projects that require more memory than x86 can provide. The x64 Clang/C2 toolset also gives more compatibility with projects that compile with the x64-hosted MSVC toolset.

This post focuses on changes since the last release. For a more detailed discussion of the Clang/C2 toolset please read “Clang with Microsoft CodeGen (March 2016) released” and any of the posts tagged with the keyword “clang”.

This release revises the version of C2.dll to 19.0.25317.0.

How to enable the x64-hosted Clang/C2 compiler

To change your Visual Studio project to use the x64-hosted tools, you need to set the ‘PreferredToolArchitecture’ MSBuild property to ‘x64′. This will set your project to use the x64-hosted version of the entire C++ toolset, whether you’re using Clang/C2 or the MSVC compiler.

There is currently no method to force the 64-bit tools in Visual Studio so you have to edit your .vcxproj file. Insert the following after the <Import...Microsoft.Cpp.Defaults line:

  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
  <PropertyGroup>
    <PreferredToolArchitecture>x64</PreferredToolArchitecture>
  </PropertyGroup>

The edit needs to be made after importing the properties file as it may get changed in one of the files it imports based on your host architecture. If you use -v (Enable Verbose mode in the IDE) in your compiler options, you’ll see the full path to clang.exe in the output–make sure it includes the amd64 subdirectory.

There are more details about this technique in this Stack Overflow post: How to make Visual Studio use the native amd64 toolchain.

If you use a build system other than MSBuild, you’ll need to get your build system to pick up clang.exe from ‘C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\Clang 3.7\bin\amd64\{x86|amd64|arm}\clang.exe’ instead of ‘C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\Clang 3.7\bin\x86\{x86|amd64|arm}\clang.exe’

How to get this update

Through VS Notifications

If you already have the March 2016 update of Clang/C2 installed you should receive a notification in the VS Notifications pane that this update is available. Click on that notification to begin the installation process.

Use the VS installer

• Navigate to Control Panel->Programs->Programs and Features
• Right click on “Microsoft Visual Studio Enterprise 2015″
• Click “Change”
• Click “Modify”
• Select “Clang with Microsoft Codegen”. Select the May 2016 release. The previous release is marked as “Deprecated”.
• Note: Because of very recent changes to the Visual Studio “15” installer, this version of Clang/C2 is only available on Visual Studio 2015, not the next version of Visual Studio.

Create new project

When creating a new project you should see an option for two Clang projects in the Cross Platform section of the Visual C++ templates. Selecting one of these should install or update your Clang/C2 tools to the latest version. Note that we are in the process of removing the version number from the description due to maintenance issues.

Bug Reporting

When submitting bug reports that are specific to Clang/C2 (i.e. they are not reproducible in Clang/LLVM), make sure to:

• Submit your issues at https://connect.microsoft.com/VisualStudio
• Prefix your bug report title with [Clang/C2]
• When applicable, make sure to include preprocessed source(s) and associated run script(s) that are reported when you encounter an internal compiler error. Search for the string “PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:” in your build log.

As always, we’re eager for you to try out the changes and give us feedback in the comments, by email at clangc2@microsoft.com, or through any of the usual channels: User Voice, Suggestions, Connect (for bugs), or even Send-A-Smile. We love hearing from you!

It has been an exciting year since the C++ Core Guidelines and checkers were announced starting with Bjarne Stroustrup’s opening keynote at CppCon 2015. We’ve shipped multiple releases of our CppCoreCheck analysis tools through NuGet. The Clang community has kept up the pace implementing the C++ Core Guidelines checks in Clang-Tidy. And we’ve seen a steady stream of commits to our implementation of the Guidelines Support Library on GitHub.

The most exciting thing is the amount of feedback and engagement we’ve seen from our developer community. Lots of you have sent suggestions, feedback, and bugs to us at cppcorecheck@microsoft.com. It’s really helpful to have your feedback and contributions to this work while it’s still in the early stages. Thank you!

When we released the first preview of the lifetime checker we put it into a separate DLL. The complex analyses in the lifetime checker makes it slower than the regular core checkers, and the early state of the work means that there are more bugs. Separating it into its own DLL allowed you to install the bounds and type checkers without the lifetime checker. But we heard from you that you want to choose when you run each checker without having to go back to NuGet.

We’re now shipping both the experimental checkers, including the lifetime checkers, and the regular checkers in one NuGet package (the GSL is still installed as a dependency.) New MSBuild scripts allow us to extend project settings so that you can select specific extensions during code analysis. This means that you can enable or disable either of the checkers individually in your project settings. You can have the release checkers run during debug builds, for example, and turn on the experimental checkers for your release builds. Or you can create a custom configuration that runs the code analysis checkers.

Want to try it out?

Just install the checkers as you always have from NuGet. (Detailed instructions are in the first blog post about CppCoreCheck.) If you’ve got the separate ExperimentalCoreCheck package installed, you should uninstall that first–all of its functionality is now in the regular CppCoreCheck package. See below for instructions on installing and uninstalling NuGet packages.

The new MSBuild scripts included allow you to separately configure what checkers run. Just go to the project’s properties dialog and select “Configuration Properties\Code Analysis\Extensions”. Here you can select the rules checkers you want to run for that configuration. You can select a different set of checkers for each configuration.

Uninstalling (and installing) NuGet packages

If you need to uninstall the old ExperimentalCppCoreCheck package you can do so in the Manage NuGet Packages console. Pull up the Manage NuGet Packages by right clicking on your project or solution, or by typing in the QuickLaunch box:

Click on the “Installed” tab and select the Experimental package. Click the Uninstall button on the right to uninstall it.

Notice that there’s an Update indicated on the Manage Packages window. If you click on that tab you can update the CppCoreCheck package right in the same window.

Send us your feedback!

As always, we want to hear your thoughts. The experimental checkers are still in early development, so we’re not looking for standard bug reports on anything that’s in the experimental set. But if you run into issues on the release checkers, or have thoughts about the design direction of the experimental rules, please send us your feedback at cppcorecheck@microsoft.com. And we love to hear from you through any of the usual channels: User Voice, Suggestions, Connect (for bugs), or even Send-A-Smile.

This blog post written by Gabriel Dos Reis, Ulzii Luvsanbat, and Andrew Pardoe.

In Visual C++ 2015 Update 3 we are introducing tools to help you control the version of the ISO C++ programming language you depend on and the version you want VC++ to enforce in your projects. We’re creating a series of new switches that correspond to versions of the C++ language, starting with /std:c++14 and /std:c++latest.

Why add these switches?

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.

Switches for language versions

We want to help you keep your compiler toolchains up to date with the newest versions of Visual Studio. To help you stay current without requiring you to immediately move your code to the latest C++ standards we’re introducing a series of switches that allow you to opt-in to versions of the C++ standard. As we’re starting with VS 2015 Update 3, the first switch in the series will be /std:c++14, reflecting the state of the Visual C++ compiler today. We also introduce a /std:c++latest switch that will reflect compiler and library work proposed in the current standard draft. Note that similar switches are available in other compilers, including GCC and Clang.

The switches enable new features from each C++ Standard, or any behavior breaking changes on existing features. They are not meant to track MSVC-specific conformance bugs. Bug fixes will continue to happen independently of language version switches. If a bug fix prompts source code changes to be more standards conformant, the compiler will provide well-defined diagnostic messages. And we’ll continue to keep an extremely high bar for bug fixes that require source code changes, and we’ll continue to document each fix and its impact (this page lists the existing compiler conformance improvements documentation for VS 2015.)

/std:c++14

The /std:c++14 switch enables the set of C++14 features implemented by the Visual C++ compiler, modulo conformance bug fixes and ongoing feature work (such as for constexpr, expression SFINAE, 2-phase name lookup, etc.) Using the /std:c++14 switch will always instruct Visual C++ to compile your code according to the C++14 standards and associated Defect Reports.  This is the default language version in this update.

Each version of the C++ Standard generally builds upon previous versions, except when they don’t. Consequently, each language version (for versions after C++14, because we are starting with /std:c++14) will select C++14 semantics in addition to any other requirements (including feature modification or removal) instructed by that language version. Using a later switch in the series such as /std:c++latest (see the section on /std:c++latest below) will turn on post-C++14 features in addition to C++14 features. Note that there is no plan to add a C++11 switch.

There are some post-C++14 features already implemented in previous releases of the Visual C++ compiler. To avoid breaking changes for users who have already taken dependencies on these features we’ll leave them under the /std:c++14 switch. They include the following features, all of which have already shipped in Visual Studio 2015 Update 2:

• New rules for auto with braced-init-lists
• typename in template template-parameters
• Removing trigraphs
• Attributes for namespaces and enumerators
• u8 character literals

/std:c++latest

The /std:c++latest switch will move forward the set of features implemented by Visual C++ with each new version of the C++ standards Working Draft. Currently it will track features that we add for the proposed post-C++14 draft standard. When the next standard is approved, the semantics opted-in with the /std:c++latest will be covered by /std:c++17 (assuming that the next standard is C++17, but the standards committee working group never ceases to surprise) and /std:c++latest will move forward to track the next draft standard’s features. In another words, with /std:c++latest, you will always get the set of all new features currently implemented and on by default. (The /std:c++latest switch will not turn on new features guarded by the /experimental switch.)

Summary

Visual Studio 2015 Update 3 introduces two new switches (/std:c++14 and /std:c++latest) to give you control over the version of the C++ programming language you want to use in your projects. In this update, if you specify a language version that isn’t any of those, the compiler will ignore the switch (with a warning) and default to C++14. You can try the compiler out today–see this blog post for details on how to get the VS 2015 Update 3 RC: https://blogs.msdn.microsoft.com/visualstudio/2016/06/07/visual-studio-2015-update-3-rc/

In closing

As always, we’re eager for you to try out the changes and give us feedback in the comments below, by email at visualcpp@microsoft.com, or through any of the usual channels: User Voice, Suggestions, Connect (for bugs), or even Send-A-Smile. We love hearing from you!

This post written by Xiang Fan and Andrew Pardoe

Last December we blogged about partial Expression SFINAE support in VS 2015 Update 1. Some of the things we heard from you after that post are that you wanted better Expression SFINAE support, especially for popular libraries such as Boost and Range-v3. These libraries have been our focus over the last few months.

What is SFINAE?

As a reminder, SFINAE is an acronym for ‘Substitution Failure Is Not An Error’. The idea is that when the compiler tries to specialize a function template during overload resolution, it is ok if the specialization fails as long as there are other valid candidates. C++11 introduced features like decltype and constexpr, and it is more common to have expressions during the template argument deduction and substitution process. The C++ standards committee clarified the SFINAE rules for expressions in C++11.

Boost support

The big news with this update is that Boost now compiles correctly with MSVC without defining the macro BOOST_NO_SFINAE_EXPR. We worked with the Boost maintainers and community to make sure we got it correct. There are still libraries and open source projects that build on top of Boost that have blocking issues. Please let us know if you run into any issues. You can email us at visualcpp@microsoft.com or use any of the feedback channels below.

There are still three failing tests in the Boost test suite when compiling with MSVC. Two test failures relate to using the noexcept operator in a template type argument. We currently parse it immediately, even in a dependent context. One test failure is a Boost library issue that we’ve reported to the maintainers.

Range-v3 support

While we’ve been testing with Range-v3, our progress isn’t as complete as it is with Boost. We went through all range-v3 tests and identified various issues in it. We logged over 50 bugs internally to track our progress and have fixed about half of these bugs. Issues remain in many different feature areas, such as name lookup, friend functions, variadic templates, alias templates, default template arguments, constexpr and noexcept. There are other issues mentioned in the  What’s Remaining section below.

Improvements since Update 1

Our implementation is still partial , but we’re almost done. We’ve made a lot of progress since Update 1. First, though let’s talk about why it’s so hard to get Expression SFINAE working in the MSVC compiler.

MSVC’s token stream parser

The MSVC compiler has been around since before C++ had templates–we’re now working around design decisions that once made sense. MSVC traditionally took a token stream-based approach to parsing templates. When we encounter a template in your code we capture its body as a sequence of tokens without any attempt to understand what the tokens mean. Storing the body as a stream of tokens makes analysis of trailing return types containing decltype-specifiers imperfect, especially in SFINAE contexts.

We have now implemented a recursive-descent parser that generates high level unbound trees for expressions and employed this to analyze the expression argument of decltype in a much more precise way, allowing a better implementation of Expression SFINAE. The recursive descent parser is a work in progress; currently, it can parse only C++ expressions but we’re going to soon expand it to parse the entire C++ syntax and make it the basis for implementing features such as two-phase name lookup. These features have been almost impossible to implement with the token stream-based parser. As work proceeds, the remaining gaps in Expression SFINAE will also be filled.

If you’d like to read more about the changes we’re making to the parser you can find more in this blog post: Rejuvenating the Microsoft C/C++ Compiler.

What’s working now?

Because we’re now generating parse trees for decltype expressions a number of patterns work correctly in Update 3.

• We’ve implemented checking for dependent expression using the new parse tree in the compiler. That fixes this Connect issue reported for a failure compiling Chromium.
• We’ve implemented ability to distinguish different expressions inside decltype using parse tree. Here’s an example simplified from the Boost thread library:

  template<class T>
  struct remove_reference
  {
      typedef T type;
  };
  
  template<class T>
  inline T&& forward(typename remove_reference<T>::type& t)
  {
  	return static_cast<T&&>(t);
  }
  
  template<class T>
  inline T&& forward(typename remove_reference<T>::type&& t)
  {
  	return static_cast<T&&>(t);
  }
  
  template <class Fp, class A0, class ...Args>
  inline auto invoke(Fp && f, A0 && a0, Args && ...args)
  -> decltype((forward<A0>(a0).*f)(forward<Args>(args)...))
  {
  	return (forward<A0>(a0).*f)(forward<Args>(args)...);
  }
  
  template <class Fp, class A0, class ...Args>
  inline auto invoke(Fp && f, A0 && a0, Args && ...args)
  -> decltype(((*forward<A0>(a0)).*f)(forward<Args>(args)...))
  {
  	return ((*forward(a0)).*f)(forward(args)...);
  }

• A couple of test cases simplified from Range-v3 now work.

  int f(int *);
  
  namespace N {
  	template<typename T> T val();
  
  	template<typename T> using void_t = void;
  
  	template<typename T, typename = void> struct trait {};
  	template<typename T> struct trait<T, void_t<decltype(f(val<T>()))>> {
  		typedef decltype(f(val<T>())) type;
  	};
  }
  
  N::trait<int *>::type t1;
  
  struct S {
  	template<typename T> static T val();
  
  	template<typename T> using void_t = void;
  
  	template<typename T, typename = void> struct trait {};
  	template<typename T> struct trait<T, void_t<decltype(f(val<T>()))>> {
  		typedef decltype(f(val<T>())) type;
  	};
  };
  
  S::trait<int *>::type t2;
  

• Also, this example:

  int g;
  
  template<typename T>
  using void_t = void;
  
  template<typename T, typename = void>
  struct S1 {};
  
  template<typename T>
  struct S1<T, void_t<decltype(g + T{}) >> {};
  
  struct S2 {
  	int *g;
  	auto f() -> decltype(S1<int>());
  };
  

What remains to be done?

• constexpr used inside template arguments:
  Whenever we see a function call in a template non-type argument, we parse and do semantic analysis on it immediately. This will prevent its use in a dependent context. constexpr is commonly used as template non-type argument in range-v3.

  		#include <type_traits>
  
  		#if defined(WORKAROUND1)
  		// Alternative for type_trait.
  		template<typename T, std::enable_if_t<std::is_pointer<T>::value> * = nullptr>
  		#elif defined(WORKAROUND2)
  		// If the constexpr is always valid, it can be moved into a helper class
  		template<typename T>
  		struct helper {
  			static const bool value = T{};
  		};
  		template<typename T, std::enable_if_t<helper<std::is_pointer<T>>::value> * = nullptr>
  		#else
  		// VC does semantic analysis on 'std::is_pointer<T>{}' prematurely
  		// and gives error on the function declaration
  		//   error C2512: 'std::is_pointer<_Ty>': no appropriate default constructor available
  		template<typename T, std::enable_if_t<std::is_pointer<T>{}> * = nullptr>
  		#endif
  		short f(const T &);
  
  		char f(...);
  
  		int main()
  		{
  			int *p = nullptr;
  
  			static_assert(sizeof(f(0)) == sizeof(char), "fail");
  			static_assert(sizeof(f(p)) == sizeof(short), "fail");
                  }
  

• Decltype and dependent expressions inside alias templates:
  If the definition of alias template contains decltype or dependent expression, we will capture its tokens and re-parse it later. Because the tokens don’t resolve the name (they only store the identifier), sometimes the alias specialization will find the wrong symbol during re-parse and you may get incorrect SFINAE result. For example, these two code snippets:

  // General case
  template<typename> struct S {
  	using type = int;
  };
  template<typename T> using type1 = decltype(S<T>{});
  template<typename T> using type2 = typename type1<T>::type;
  type2<int> i;
  

  // This case impacts SFINAE. Simplified from range-v3
  
  template<typename> struct S1 {};
  
  template<typename T> T declval();
  
  void f(int *);
  
  #ifdef WORKAROUND
  template <typename T>
  using void_t = void;
  template <class T, class V = void> struct helper {};
  template <class T> struct helper<T, void_t<decltype(f(declval<T>()))>> {
  	typedef decltype(f(declval<T>())) type;
  };
  template<typename T>
  using S2 = typename helper<T>::type;
  #else
  template<typename T>
  using S2 = decltype(f(declval<T>()));
  #endif
  
  template<typename U, typename T, S1<S2<U>> * = nullptr>
  short g(U, T);
  
  char g(...);
  
  void h()
  {
  	 // we are supposed to use 'std::nullptr_t' to specialize S2<U>,
           // but we incorrectly use 'int' during re-parsing
  	static_assert(sizeof(g(nullptr, 1)) == sizeof(short), "fail");
  	 // we are supposed to use 'int' to specialize S2<U>,
           // but we incorrectly use 'std::nullptr_t' during re-parsing
  	static_assert(sizeof(g(1, nullptr)) == sizeof(char), "fail");
  }
  
  

• Pack expansions used inside decltype expressions:We are currently not able to detect pack expansions inside decltype, so it won’t be expanded correctly in some cases. You may get incorrect SFINAE result because of this.

  // Example from range-v3:
  
  #ifdef WORKAROUND
  template<typename T>
  struct helper1 {};
  template<typename Fun2, typename ...Args2>
  struct helper2 {
  	// pack expansion works for function template
  	template<typename Fun, typename ...Args>
  	static short f(helper1<decltype(val<Fun>()(val<Args>()...))> * = 0);
  	template<typename Fun, typename ...Args>
  	static char f(...);
  
  	static const bool value
              = sizeof(helper2::f<Fun2, Args2...>(0)) == sizeof(short);
  };
  
  template<bool, typename Fun, typename ...Args>
  struct helper {
  };
  template<typename Fun, typename ...Args>
  struct helper<true, Fun, Args...> {
  	typedef decltype(val<Fun>()(val<Args>()...)) type;
  };
  
  template<typename Fun, typename ...Args>
  using result_t = typename helper<helper2<Fun, Args...>::value, Fun, Args...>::type;
  #else
  template<typename Fun, typename ...Args>
  using result_t = decltype(val<Fun>()(val<Args>()...));
  #endif
  

Send us feedback!

As always, we want to hear from you. If you know of any issues with Expression SFINAE not covered in this post, please send us feedback through Send us your feedback in the comments below, through Connect, or by sending us a mail at visualcpp@microsoft.com. Thank you!

Try out the new compiler today! The official VS announcement about the VS 2015 Update 3 RC release is here: https://blogs.msdn.microsoft.com/visualstudio/2016/06/07/visual-studio-2015-update-3-rc/

The C++ compiler team is excited for you to try out the compiler in Visual Studio 2015 Update 3. We’ve made significant progress towards C++ standards conformance between the first release of Visual Studio 2015 and VS 2015 Update 3. Update 3 also has improvements in expression SFINAE, nested namespaces, and generalized range-based for loops. Lastly, we’ve got a new set of switches that help you to control the version of the ISO C++ programming language you depend upon in your code.

We’ve also fixed almost 200 compiler bugs since Update 2, many of which came from your reports on Connect. Thank you! We know that the occasional bug fixes can prompt source code changes to be more standards conformant. When source changes are needed, the compiler will provide well-defined diagnostic messages and we’ll continue to document each fix and its impact on this page: compiler conformance improvements documentation for VS 2015. Know that we’ll continue to keep an extremely high for bug fixes that require source code changes.

Let’s dive into some of the feature improvements we’ve made in the compiler for VS 2015 Update 3. Many of these changes are helping our compiler to conform to existing C++11 and C++14 Standards features. And some of our changes are forward-looking; that is, we implemented features expected to be in the next version of C++.

• Standards versioning: In Visual C++ 2015 Update 3 we are introducing tools to help you control the version of the ISO C++ programming language you depend on and the version you want VC++ to enforce in your projects. We’re creating a series of new switches that correspond to versions of the C++ language, starting with /std:c++14 and /std:c++latest. Read more in this blog post: Standards version switches in the compiler.
• Expression SFINAE: We’ve been working hard on improving our Expression SFINAE support, especially for popular libraries such as Boost and Range-v3. Read more about it in this blog post: Expression SFINAE improvements in VS 2015 Update 3
• Nested namespaces: The next version of C++ includes a more concise way to define nested namespaces. Instead of typing

      namespace A {
          namespace B {
              namespace C {
              ...
              } 
          }
      }
  

  you can write

  namespace A::B::C {
      ...
  }
  

  Visual C++ supports the more concise syntax in Update 3. This feature is expected in the next version of C++ but it’s supported in Update 3 today under the /std:c++latest switch (see Standards Versioning, above.) You can read more about the feature in the proposal: Nested namespace definition.

• Generalized range-based for loops: Generalized range-based for loops no longer require the <begin> and <end> iterators to have the same type. This feature is expected in the next version of C++ but it’s supported in Update 3 today under the /std:c++latest switch (see Standards Versioning, above.) You can read more about the feature in the proposal: Generalizing the Range-Based For Loop.

In closing

As always, we’re eager for you to try out the changes and give us feedback in the comments below, by email at visualcpp@microsoft.com, or through any of the usual channels: User Voice, Suggestions, Connect (for bugs), or even Send-A-Smile. We love hearing from you!

We’re happy to provide an update on the VC++ for Linux extension which has a new release today. Go get it now (and come back). We’ve had a few drops since our initial release to make general improvements and to address your feedback. We’ll tell you here about some new features in this release, explain how your feedback has guided us, give some usage tips, and show you how to use the extension with the Intel Edison board for your IoT projects.

Please consider taking this short survey to help us learn more about how you approach cross platform development. We know there are a lot of different Linux systems out there used in many ways. We’d love to hear from you about how you are using the extension. We’re also interested in hearing directly from you, so if you are willing to be contacted, please let us know in the survey. Talking directly to people about how they are using this has already helped us tremendously and we’d like to improve further. We do hope to identify some people we can contact on a more regular basis when we need input or have early bits to try out.

We want to remind you though that things are still moving quickly. We’re making changes to the file that tracks the connections. On updates we overwrite the existing file which is no longer compatible which unfortunately means any existing defined connections are lost. We will stop doing that as our functionality starts to stabilize and mature.

Console window

The most visible change in this update is that we’ve added a console window for interacting with your remote executables. This window shows not just the output of your program but can also take input. To activate this window use the menu Debug, Linux Console. This is what it looks like in action.

Here is a simple program you can try these features out with.

#include <cstdio>

void log(char filename[], char visitor[])
{
	FILE * pLog;
	pLog = fopen(filename, "a");
	if (pLog != NULL)
	{
		fputs(visitor, pLog);
		fputs("\n", pLog);
		fclose(pLog);
	}
}

int main(int argc, char* argv[])
{
	if (argc != 2)
	{
		printf("Please pass filename as input parameter\n");
		return 1;
	}
	char input[20];
	printf("What IDE are you using?\n");
	scanf("%19[0-9a-zA-Z ]", input);
       printf("%s! You can use that with me?!\n", input);
	log(argv[1], input);
       return 0;
}

Specify a filename in the Command Arguments input on your project’s Debugging property page. You can set a working directory on that page as well, if it is not set your home directory will be the working directory.

Reported issues

We want to thank everyone who has been reporting issues to us. Your feedback is very important. It does more than just help us prioritize things we know about, it helps us identify and fix the things we didn’t know about. Our very first update was to address a crash report that we hadn’t encountered before. Some of the other things like access denied with read only files we hadn’t come across in our testing yet. It would have taken us a long time on our own to encounter that but it was critical for a source control work flow that was reported to us. Some of the other things may have been things we were aware of, knowing they mattered raised their importance.

Here is a sampling of issues that were reported by our users. You’ll find a full list of changes at the end of this post.

• Crash during logon
• Added support for working directory and command line arguments for the debugged process
• Added ability to use files outside the project directory
• Fixes an access denied bug when uploading read only files
• Fix for login as root
• Fix for empty output file name extension, now the output can have no file extension

Again, thank you for your feedback and keep it coming.

Verbose build output

We’ve gotten a lot of questions about what exactly are the arguments being passed to GCC. Our build output doesn’t make this obvious, but you can enable it. There are two ways to get to the same place to change this setting. In the quick input window search for “verbosity”, or under Tools, Options go to Projects and Solutions, Build and Run. Now for the option of MSBuild Project output verbosity change it to diagnostic to see everything in your output window when you build. This can really help you find what exactly was passed to GCC to build your program if you are having issues.

Getting your include files

Everyone loves IntelliSense, but we’re not yet synchronizing the include files from your Linux system. Everyone has their own ways to either share or copy these files which is great. I wanted to share a really simple way to accomplish this I used in prepping the next section on the Intel Edison. I simply grab the whole folder locally onto my Windows box using PSCP.

pscp -r root@192.168.2.15:/usr/include .

Now on your project properties go to the VC++ Directories page and add your local path.

How to use the VC++ for Linux with the Intel Edison board

Using the VC++ for Linux extension with the Intel Edison board is largely like any other Linux system. First you’ll want to make sure you’ve setup your device following Intel’s instructions. You should be able to connect to your Edison via our connection manager once you have connected it to your Wi-Fi network. If you need a direct connection to your Edison use these instructions for using Ethernet over USB with your Edison which will also work with our connection manager.

The Edison makes it easy to start building an IoT application with sensor data. Accessories like the Arduino shield open make it easy to connect add-ons like the Grove shield from Seeed Studios. That shield lets you use any of the many available Grove sensors without having to worry about wiring a circuit on a breadboard, you can just get straight to your code. Intel has made this even easier to use with their UPM sensor library that covers a broad range of sensor including the Grove ones.

Shown here is an Edison compute module on an Arduino expansion board with a Grove shield attached and a temperature sensor plugged in.

In Visual Studio, create a new project, and under VC++, Cross Platform, Linux select Empty Project. Make sure that you set your solution platform to x86 when targeting the Edison. Add a C++ file to the project and use the code from this Grove Temperature Sample from Intel. The UPM libraries are part of the default Yocto Linux image used on the Edison so no additional setup is needed to acquire them. You should change the include statement in the sample to properly reference their location as follows:

#include <upm/grove.h>

With that change, you are ready to build and run your code. Here you can see the output of this sample in Visual Studio’s debug mode. If you are wonder about that first output line the first read from this type of sensor is often a bit off.

To enable IntelliSense follow the instructions above for copying your include files locally from your Edison. At this time, we do have an IntelliSense bug that impacts this sample that will be fixed in a future update.

In a future post we’ll cover taking this sample further by connecting it to Azure IoT Hub.

Changes

We always post our change logs on the Visual Studio Gallery page for the Linux extension, but here is the complete tally since our original release.

6/6/2016 1.0.3

• Added a console I/O Tool Window for interacting with remote process launched from VS
• Added support for working directory and command line arguments for the debugged process
• Added ability to use files outside the project directory
• UI for system information (OS/architecture) in the Tools – Options
• C++14 support IntelliSense bug fix
• Connect to Linux dialog UI bug fixes
• Linux Connections UI remove connection after add bug fix
• Fixes an access denied bug when uploading read only files
• Fixes -x c, -x c++ bug and compiling as C
• FreeBSD, OSX partial support, including connections, compile and link. Debugging is not supported yet.
• Performance improvements

4/14/2016 v1.0.2

• Removed the dependency on Android NDK and Android MDD bits
• Intel Edison support and bug fixes
• Fix for login as root
• Fixes the occasional “4444 port in use”
• Fixes the “no such file” bug
• Local and remote ports in the Property Pages are not dependent on each other and each can be supplied individually
• Fixes a bug with removing entries from Linux Connection Manager
• Resource management (leaked sshd processes) fixes
• General robustness fixes in the Connect dialog
• Gdbserver cleanup at the end of debugging
• Improved build diagnostics and linker errors parsing from build
• Fix for empty output file name extension, now the output can have no file extension

4/4/2016 v1.0.1

• Fixed crash during login

This blog post is going to talk about how you can use Gradle to build Android libraries (.AAR) and APK’s and leverage Maven dependencies all in Visual Studio so let’s get started! If you are new to Gradle, then take a look at the gradle overview page and the User Guide.

Gradle has really been the default build system for Android for quite some time and Android developers have slowly but surely been moving to Gradle. Gradle provides flexibility as well as the ability to define common standards for Android builds. Gradle allows Android developers to use a simple, declarative DSL to configure Gradle builds supporting a wide variety of Android devices and App stores.

With a simple, declarative Domain specific language (DSL), Gradle developers can easily describe and manipulate the build logic (e.g. manifest entries – minSDKVersion, targetSDKVersion etc.), use the built-in dependency management via Maven or Ivy and essentially have access to a single, authoritative build that powers both the Android Studio IDE and builds from the command-line but this ability to use Gradle in Visual Studio has been missing until recently.

Getting Started 
With the latest Visual Studio release, if you take a look at the cross-platform C++ section in the File->New project template section, you will see a variety of templates as shown in the figure below. Notice two new Gradle templates that have been introduced.  

‘Basic Android Application (Android, Gradle)’, template as the name suggests will build an E2E android application (.APK) and the ‘Basic Library (Android, Gradle)’ template will build an AAR file also known as an Android artifact. For traditional Java users, AAR’s are similar to Jar files with the main difference being AAR files include resources such as layouts, drawables etc. This makes it a lot easier to create self-contained visual components.  For e.g. if you have multiple apps that use the same login screen, with jar’s you can share classes but not the layout itself. With AAR’s everything is bundled into one package. With that said, let us now take a look at structure of a basic Android application.

Understanding the Gradle artifacts  
As you create a new project from template, you will notice the top-level build.gradle file, located in the root project directory, defines build configurations that apply to all modules in your project. By default, the top-level build file uses the buildscript {} block to define the Gradle repositories and dependencies that are common to all modules in the project. The following code sample describes the default settings and DSL elements you can find in the top-level build.gradle.template after creating a new project.

For this project, the repositories section declares the jCenter and mavenCentral repositories, and we have also introduced a classpath dependency on a Maven artifact. This artifact is the library that contains the Android plugin for Gradle version specified in the property pages (figure below).

The module-level build.gradle.template file, located in the ‘app’ directory will allow you to configure build settings for the specific module it is located in. One thing special about this particular specific build.gradle.template file is the fact that it is based upon the experimental plugin (0.4.0) which allows for significant time reduction in configuration time. In addition to this, this experimental plugin also allows for integration with NDK and CMake build system which is important if your application contains C++ code.

A sample Android app module build.gradle.template file when using the experimental plugin outlines some of the basic DSL elements.

The apply plugin: ‘com.android.model.$(ConfigurationType)’ command specifies the kind of artifact being built. You can either set this to an application for building an .APK or a library for building an .AAR file. This configuration type can be controlled via the property pages ‘Configuration Type’ property .

The plugin name used by the experimental plugin is different than the standard plugin name ‘com.android.application’ for building an Android APK or ‘com.android.library’ in case you are building an Android aar library.

The next section in the module-specific ‘build.gradle.template’ file is the model section. The model section wraps the configuration. The Android closure is the standard way used for wrapping the SDK version used for compiling, minimum SDK version supported and more.

The next section ‘compileOptions’ allows for choosing the language level used by the compiler.

The android.buildTypes section creates a debug and release build type  for this application. Although the debug build type doesn’t appear in the build configuration file; it gets configured when the debuggable property is set to true. This allows for debugging the application on secure Android devices and configures APK signing with a default generic keystore.

The last section in the model enclosure is productFlavors. A product flavor defines a customized version of the application build by the project. A single project can have different flavors which change the generated application. Since this particular build.gradle is tailored for an NDK android application the abiFilters.add allows for building one APK per architecture easily.

The last section in this build.gradle.template file is the dependencies section. There are three kinds of dependencies, and you can find what each kind does here on the Android documentation site. This particular build.gradle.template only defines the compile.filetree dependency as shown below. The ${AarDependencies) is an addition by us which allows easy Visual Studio project referencing.

The compile fileTree(dir: ‘libs’, include: [‘*.jar’]) line tells the build system to include any JAR files inside the app/libs/ directory in the compilation classpath and in the final package of your application.

The other Gradle files that are included as the part of your project is the settings.gradle.template file. This file references all the modules that make up your project.

include ‘:app’ $(AarDependenciesSettings)

Using the NDK integration   
Using the NDK integration with Gradle in Visual Studio is easy. Typically you would need to add the ndk {} section in your model section for your module specific build.gradle.template file and potentially also use the android.sources section to provide JNI source set as specified in the android documentation  but  in Visual Studio in order to incorporate a native C/C++ component all you need to do is create a new native component through the Cross-Platform – Android section  and then add it via the typical project reference from the Gradle project as shown below. Visual Studio will automatically take care of packaging your native library in the Android application you are building.

Alternatively you can also use the standard approach for including JNI sources using the experimental Gradle plugin as well if that works out better for you. Google provides a good list of samples for Android NDK and Gradle in this repository. With minor changes, mainly involving copying over contents from the ‘build.gradle’ -> ‘build.gradle.template’ files , those samples would work for you in Visual Studio. We are currently in the process of making this process happen automatically by providing you folks with an Android Studio -> Visual Studio Android project converter. If this converter really interests you please leave your contact information here or reach out to me.

Referencing Android libraries in your Android project    
Generally, Android applications built in Visual Studio mainly use C++. Every now and then even for these C++ heavy applications there can be a need to include Android libraries such as AARs and JARs into your Android application. These could be homegrown Android artifacts built for the purposes of sharing common code, assets and utilities.

With this release of Visual Studio, we have made the process really easy for you to do that as well. In order to create and reference an AAR file you can simply do so by creating a new AAR from the File->New project menu (Basic Library (Android, Gradle)) and then include it in your Android application by adding it through a project reference as shown in the figure below.

An example: Incorporating the Facebook SDK in your Android app
Now that we have a basic understanding of how the Gradle build system works, lets now go ahead and show off the real power of the build system. As mentioned earlier, Gradle makes it simple to integrate with external repositories. In order to leverage the Facebook SDK (instructions here) all one has to do is use the compile dependency command in the module specific build.gradle.template file and add the following line (given that we have already specified mavenCentral() and JCenter() repositories in the root build.gradle file).

compile ‘com.facebook.android:facebook-android-sdk:4.7.+’

This command declares a remote binary dependency on the version 4.7 and  above for the Facebook SDK. At build time Gradle will now automatically pull the dependency from the jCenter repository specified in the top-level build.gradle.template file.

This mechanism not only allows you to specify and incorporate the Facebook SDK as a build time artifact but also allows Visual Studio to power the Java language service experience with features like Intellisense extending their functionality for the Facebook SDK set of API(s) as well as shown  in the figure below!

Wrap Up   
This summarizes the current support for building Android applications with Gradle for Visual Studio 2015 Update 3. We look forward to you trying out these new features and sharing your feedback either through Send-A-Smile/Frown (use #cpp2015), Connect, User Voice or down below in the comments.