The Visual C++ team wants to better understand how you use libraries in your day-to-day development work. Whether you&rsquo;re publishing libraries, finding libraries that work on the Microsoft platforms for which you&rsquo;re building y...

The Visual C++ team wants to better understand how you use libraries in your day-to-day development work. Whether you&rsquo;re publishing libraries, finding libraries that work on the Microsoft platforms for which you&rsquo;re building your apps, or integrating libraries into your project and build systems, we want to hear from you so we can make the right investments in Visual Studio tooling.
Tell us what works, what doesn&rsquo;t, and what&rsquo;s the most important change we could make in Visual Studio to improve how you work with C++ libraries. Is there an open source library you feel is missing from your favorite Microsoft platform? We want to know about it! And yes, there are even some bonus questions about NuGet at the end. :-)
Completing this questionnaire should take about 10 minutes to finish, so take your laptop on your next coffee break and give us an earful.
Click here to go to the survey.
Thank you in advance for taking the time to give us feedback!

Going Native 2013 ended a few weeks ago, but the sessions live on in a series of videos on Channel 9. Don't have time for all of them? Here are some of the most-viewed sessions:
Bjarne Stroustrup, The Essence of C++: With Examples in ...

Going Native 2013 ended a few weeks ago, but the sessions live on in a series of videos on Channel 9. Don't have time for all of them? Here are some of the most-viewed sessions:
Bjarne Stroustrup, The Essence of C++: With Examples in C++84, C++98, C++11, and C++14
Andrei Alexandrescu, Writing Quick Code in C++, Quickly
Sean Parent, C++ Seasoning
Herb Sutter, Keynote: Herb Sutter - One C++
Stephan T. Lavavej, Don't Help the Compiler
Scott Meyers, An Effective C++11/14 Sampler
Which session did you enjoy the most (and why)?

Recently we recorded a session for 'Vector Calling Convention' on Channel 9 , as part of the &ldquo;Going Native&rdquo; series.
Vector calling convention is a new calling convention (specially for vector types) we introduced in the VS...

Recently we recorded a session for 'Vector Calling Convention' on Channel 9 , as part of the &ldquo;Going Native&rdquo; series.
Vector calling convention is a new calling convention (specially for vector types) we introduced in the VS-2013.
The video for this recording can be found here.
For more information about Vector Calling Convention please view our blog.

A compiler can only optimize away data or a function if a compiler can prove that the data or function will never be referenced. In a non-LTCG compile (i.e. a build with Whole Program Optimization (WPO) disabled) the compiler's visibilit...

A compiler can only optimize away data or a function if a compiler can prove that the data or function will never be referenced. In a non-LTCG compile (i.e. a build with Whole Program Optimization (WPO) disabled) the compiler's visibility is only limited to a single module (.obj), so for data and function that has global scope, the compiler will never know if other modules will be using them. As a result of this compiler can never optimize them away.
Linker has a good view of all the modules that will be linked together, so linker is in a good position to optimize away unused global data and unreferenced functions. The linker however manipulates on a section level, so if the unreferenced data/functions are mixed with other data or functions in a section, linker won't be able to extract it out and remove it. In order to equip the linker to remove unused global data and functions, we need to put each global data or function in a separate section, and we call these small sections "COMDATs".
(/Gw) Compiler Switch
Today using the (/Gy) compiler switch instructs the compiler to only package individual functions in the form of packaged functions or COMDATs, each with its own section header information. This enables function-level linkage and enables linker optimizations ICF (folding together identical COMDATs) and REF(eliminating unreferenced COMDATs). In VS2013 (download here), we have introduced a new compiler switch (/Gw) which extends these benefits (i.e. linker optimizations) for data as well.
For further understanding let us take a look at an example below. Feel free to try them out yourselves:
Figure 1: Linker optimizations (i.e. REF) triggered from using the /Gy compiler flag
If a user compiles the code snippets in figure 1 (foo.cpp and bar.cpp) with/without the /Gy compiler flag and subsequently links (link /opt:ref /map foo.obj bar.obj) it with the linker optimizations enabled (i.e. /opt:ref), in the resultant map file generated one can observe that function 'foo' have been removed. However one can still observe the occurrence of global data 'globalRefCount' in the map file. As mentioned before, /Gy only instructs the compiler to package individual functions as COMDATs and not data. Additionally, supplying the /Gw compiler flag in addition to the /Gy flag allows packaging of both data and functions as COMDATs allowing the linker to remove both function 'foo' and 'globalRefCount'.
(/Gw) with LTCG (Whole Program Optimization)
Given that with LTCG enabled, the compiler visibility extends beyond that of a single module it might not be obvious to understand what a user might gain from enabling this feature with WPO builds. For example, if you compile the example depicted in figure 1 with WPO the compiler can optimize away both the function 'foo' and data entity 'globalRefCount'. However if the example described above is slightly changed to what's depicted in the figure below, then just compiling with WPO does not help. Once an address of a global variable is taken it is very hard for the compiler to prove that the global is not read or written to by other functions in the magic world of pointers and the compiler gives up optimizing such scenarios even with WPO enabled.
But with the help of /Gw, linker can still remove unreferenced data entities here, because linker's REF optimization will not be blocked by things like address taken. Linker knows precisely whether it's referenced or not because any reference to global data would show up as a linker fixup (coff relocation), and that has nothing to do with address taken or not. The example below may look like some hand-made case, but it can be easily translated to real world code.
Figure 2: Address of a global variable is taken
With and with only WPO enabled builds, we also benefit from linker ICF optimization (link /ltcg /map /opt:i