Huge thanks to Garrett and the awesome NuGet team for bringing NuGet goodness to C++! 

Download NuGet 2.5 
Download the tools to build C++ packages

[00:00] GoingNative();// Charles and Ale construct the show. Sorry about missing last month! Milan update. NuGet.
[02:25] Charles interviews Garrett Serack about NuGet for C++
[39:04] ~GoingNative(); // Please send any and all feedback about NuGet for C++ to us!

More information:

NuGet Team blog post on NuGet for C++
VC++ Team blog post on NuGet for C++
Building Native Libraries for NuGet with CoApp's Powershell Tools (video)
Consuming Native NuGet Packages in Visual Studio (video)

We really want to hear from you, so please tweet feedback to @C9GoingNative (follow us!) and send your requests, ideas, complaints, praises, hate mail, and love letters to C9GoingNative@hotmail.com. We will read and respond to all messages! That's how we roll, brothers and sisters. If you are a Facebook user (who isn't these days?), then please join our C9::GoingNative Facebook group.

Gokhan discusses how he used the Starter Kit as a base for learning about DirectX programming, and demonstrates how he used the Visual Studio Shader Designer to create some of the effects in his app.

• [00:00] - Gokhan and Roberto talk about the app and Gokhan's experiences with DirectX and the Starter Kit
• [10:56] - Gokhan demos the Virtual Experiment Laboratory app
• [14:32] - Behind the scenes - making a dynamic sprite with the Visual Studio Shader Designer
• [18:37] - Behind the scenes - making an animated flame with the Visual Studio Shader Designer

Come watch the Starter Kit and the Visual Studio graphics tools in action to create rich 3D user interfaces for your app.

For more information, you can find Gokhan on Twitter: @gokhansengun.

Roberto is also on Twitter: @robertos_br. Please let us know if you have an app on the Store that uses the VS 3D Starter Kit!

So, how does Code Digger actually work? Why the PCL requirement? What happens when you click on the magic button, Alice?

Nikolai Tillmann and Peli de Halleux, software developers extraordinaire on MSR's RiSE team, join us again to dig into Code Digger in a casual setting (Nikolai's office, so native habitat). There is lots of geeking out at the whiteboard, of course. There is also a brief demo at the end. Tune in.

The NuGet package preview includes these types:

• ImmutableStack<T>
• ImmutableQueue<T>
• ImmutableList<T>
• ImmutableHashSet<T>
• ImmutableSortedSet<T>
• ImmutableDictionary<K, V>
• ImmutableSortedDictionary<K, V>

Interfaces for each of these types are also defined to facilitate exchange of immutable collection types that may be implemented differently to optimize for very specific performance or memory requirements.

See Andrew's blog for more detailed information (on immutable types for .NET and more. Lots of great info...).

• [09:27] - Object Oriented Programming
• [14:45] - What is a Managed Language?
• [23:47] - Why C# for OOP?
• [43:20] - C# Syntax

Full course outline:

• Mod 01: OOP, Managed Languages and C#
• Mod 02: Complex Types, Object Interfaces and Inheritance
• Mod 03: Controlling Programmatic Flow, and Manipulating Types and Strings
• Mod 04: Code Reflection and Working with Garbage Collection
• Mod 05: Type and Value Validation, and Encryption Techniques
• Mod 06: Splitting Assemblies, WinMD, Diagnostics and Instrumentation
• Mod 07: Interacting with the File System, and Leveraging Web Services
• Mod 08: Using LINQ to Objects and XML, and Serialization

Tips:

Slides are available on Lucian's blog.

Async void is a "fire-and-forget" mechanism: the caller is unable to know when an async void has finished, and the caller is unable to catch any exceptions from it. The only case where this kind of fire-and-forget is appropriate is in top-level event-handlers. Every other async method in your code should return "async Task".

This video goes into some more difficult cases like the Win8 example "overrides async void LoadSettings()". Here you're overriding the method, and can't change the signature, and can't return a Task from it. The solution is to return a Task some other way, like through a field.

The video also talks about the thorny problem of async void lambdas. WHENEVER you see an async lambda, you need to verify whether it will be a void-returning or Task-returning lambda.

Slides and source code are available on Lucian's blog.

This video introduces a new pattern for dealing with events: you can await them! Now why would you want to do that? Well, in some cases like responding to a button-click, it's fine to handle events in the way that you always have with top-level event handlers. But if you're building a complicated UI that has to orchestrate a whole load of events (StoryboardCompleted, MediaElementCompleted, PointerMoved, PointerReleased, ...) then it makes for cleaner code to await them. The key is the type TaskCompletionSource introduced in .NET4.

Here, Wolf Kienzle, Senior Research Developer, Interactive Visual Media group, Microsoft Research Redmond, explains and demos this excellent new tool for C++ developers building image, video or augmented reality apps. In effect, you can step into pixels. Excellent!

ActorFx (aka Ax) is based on the idea of the Actor Model developed by Carl Hewitt. Erik Meijer figured this model would fit perfectly into the realm of managing data in the cloud. See his paper on the topic, which is the basis for the ActorFx project. You can learn more about the Actor Model in this Channel9 video with Carl and Erik.

Here, the lead developers of ActorFx - Brian Grunkemeyer and Joe Hoag - join us to dig into some of the details of the technology. We also discuss the potential of Actors in the cloud, the problems they solve, how you program with them on the client (CloudList<T> is an interesting "cloud-enabled" type, for example), and potential applications of this approach to scalable distributed computing.

Download the slides.

Abstract:

This session in one word: Deep.

It's a session that includes topics I've publicly said for years is Stuff You Shouldn't Need To Know and I Just Won't Teach, but it's becoming achingly clear that people do need to know about it. Achingly, heartbreakingly clear, because some hardware incents you to pull out the big guns to achieve top performance, and C++ programmers just are so addicted to full performance that they'll reach for the big red levers with the flashing warning lights. Since we can't keep people from pulling the big red levers, we'd better document the A to Z of what the levers actually do, so that people don't SCRAM unless they really, really, really meant to.

Topics Covered:

• The facts: The C++11 memory model and what it requires you to do to make sure your code is correct and stays correct. We'll include clear answers to several FAQs: "how do the compiler and hardware cooperate to remember how to respect these rules?", "what is a race condition?", and the ageless one-hand-clapping question "how is a race condition like a debugger?"
• The tools: The deep interrelationships and fundamental tradeoffs among mutexes, atomics, and fences/barriers. I'll try to convince you why standalone memory barriers are bad, and why barriers should always be associated with a specific load or store.
• The unspeakables: I'll grudgingly and reluctantly talk about the Thing I Said I'd Never Teach That Programmers Should Never Need To Now: relaxed atomics. Don't use them! If you can avoid it. But here's what you need to know, even though it would be nice if you didn't need to know it.
• The rapidly-changing hardware reality: How locks and atomics map to hardware instructions on ARM and x86/x64, and throw in POWER and Itanium for good measure – and I'll cover how and why the answers are actually different last year and this year, and how they will likely be different again a few years from now. We'll cover how the latest CPU and GPU hardware memory models are rapidly evolving, and how this directly affects C++ programmers.

Part 1 -> Optimizations, races, and the memory model; acquire and release ordering; mutexes vs. atomics vs. fences

Download the slides.

Abstract:

This session in one word: Deep.

It's a session that includes topics I've publicly said for years is Stuff You Shouldn't Need To Know and I Just Won't Teach, but it's becoming achingly clear that people do need to know about it. Achingly, heartbreakingly clear, because some hardware incents you to pull out the big guns to achieve top performance, and C++ programmers just are so addicted to full performance that they'll reach for the big red levers with the flashing warning lights. Since we can't keep people from pulling the big red levers, we'd better document the A to Z of what the levers actually do, so that people don't SCRAM unless they really, really, really meant to.

Topics Covered:

• The facts: The C++11 memory model and what it requires you to do to make sure your code is correct and stays correct. We'll include clear answers to several FAQs: "how do the compiler and hardware cooperate to remember how to respect these rules?", "what is a race condition?", and the ageless one-hand-clapping question "how is a race condition like a debugger?"
• The tools: The deep interrelationships and fundamental tradeoffs among mutexes, atomics, and fences/barriers. I'll try to convince you why standalone memory barriers are bad, and why barriers should always be associated with a specific load or store.
• The unspeakables: I'll grudgingly and reluctantly talk about the Thing I Said I'd Never Teach That Programmers Should Never Need To Now: relaxed atomics. Don't use them! If you can avoid it. But here's what you need to know, even though it would be nice if you didn't need to know it.
• The rapidly-changing hardware reality: How locks and atomics map to hardware instructions on ARM and x86/x64, and throw in POWER and Itanium for good measure – and I'll cover how and why the answers are actually different last year and this year, and how they will likely be different again a few years from now. We'll cover how the latest CPU and GPU hardware memory models are rapidly evolving, and how this directly affects C++ programmers.

Part 2 -> Restrictions on compilers and hardware (incl. common bugs); code generation and performance on x86/x64, IA64, POWER, ARM, and more; relaxed atomics; volatile

See part 1: Name Lookup
See part 2: Template Argument Deduction
See part 3: Overload Resolution
See part 4: Virtual Functions
See part 5: Explicit and Partial Specialization
See part 6: New C++11 features added to the Visual C++ 2012 compiler (CTP)
See part 7: Usual Arithmetic Conversions and Template Metaprogramming

Table of contents

[00:00] GoingNative(); //Ale and Charles talk about the status of the VC++ 2012 CTP and introduce the show's topic,  the 3D Starter kit written by our guest, C++ developer Roberto Sonnino.
[02:55] Ale and Charles interview Roberto Sonnino about his 3D Starter Kit.
[30:16] ~GoingNative();// Ale and Charles destruct the show.

Over the last years .NET added many features to make writing multithreaded applications easier. This includes the Task Parallel Library (TPL) as well as the new async/await keywords features to reduce the friction when writing asynchronous code. However, it's still challenging to keep mutable state under control when multiple threads are involved. A common approach is to make use of immutable state that can be passed freely between different threads.
- Immo Landwerth

The NuGet package preview includes these types:

• ImmutableStack<T>
• ImmutableQueue<T>
• ImmutableList<T>
• ImmutableHashSet<T>
• ImmutableSortedSet<T>
• ImmutableDictionary<K, V>
• ImmutableSortedDictionary<K, V>

Interfaces for each of these types are also defined to facilitate exchange of immutable collection types that may be implemented differently to optimize for very specific performance or memory requirements.

See Andrew's blog for more detailed information (on immutable types for .NET and more. Lots of great info...).

Get Herb's slides for this session.

Herb says:

I've spoken and written on these topics before. Here's what's different about this talk:

• Brand new: This material goes beyond what I've written and taught about before in my Effective Concurrency articles and courses.
• Cutting-edge current: It covers the best-practices state of the art techniques and shipping tools, and what parts of that are standardized in C++11 already (the answer to that one may surprise you!) and what's en route to near-term standardization and why, with coverage of the latest discussions.
• Blocking vs. non-blocking: What's the difference between blocking and non-blocking styles, why on earth would you care, which kinds does C++11 support, and how are we looking at rounding it out in C++1y?

The answers all matter to you – even the ones not yet in the C++ standard – because they are real, available in shipping products, and affect how you design your software today.

Abstract:

You can't do a better job if you don't change what you're doing, but change is hard.  It's especially hard when what needs to change is your colleagues' approach to software development. Moving your team forward often requires persuading your peers to change their behavior, sometimes to do something they're not doing, other times to stop doing something they've become accustomed to.  Whether the issue is to embrace or avoid C++ language features, to adopt new development tools or abandon old ones, to increase use of or scale back on overuse of design patterns, to adhere to coding standards, or any of the plethora of other matters that affect software creation, moving things forward typically requires getting your colleagues to buy into the change you're proposing.  But how can you do that?

In this panel session, Andrei, Herb, and Scott share how they go about convincing their colleagues to change and take questions from the audience. 

This was filmed at C++ and Beyond 2012

Download Herb's slides for this session.

Abstract:

In addition to the many new C++11 features that everyone's listing, it has dawned on me over the winter that there's actually another major change that isn't being talked about anywhere, or even being listed as a change in C++11 at all as far as I know, because I and other key experts and committee members I've asked didn't fully realize that we altered the basic meaning of not one but two fundamental keywords in C++. It's a change that has profound consequences, that rewrites and/or invalidates several pieces of pre-C++11 design guidance, and that's directly related to writing solid code in a concurrent and parallel world. This isn't just an academic change, either — everyone is going to have to learn and apply the new C++11 guidance that we'll cover in this session.

I plan to talk about it first at C&B, in a session tentatively titled as above — I'll fill in the keywords later. You may already guess a few keyword candidates based on the description above, and here's a final hint: You'll hardly find two C++ keywords that are older, or whose meanings are more changed from C++98 to C++11. (No, they aren't auto and register.)

Pop Quiz: What's a Transdimensional Portal? No, not the science fiction kind a la Dr. Who, but rather something that exists today, in the center of Amsterdam, inside one of the city's oldest buildings, ready for you to experience... Tune in. It's Mike Lee time.

Really glad to have Mike on Channel 9 again. Thanks, Mike!

Here, we discuss Clojure, Groupon, and application security. Tune in!