Did Microsoft change cmd so that it works like bash now?
It think it's power shell.
LINQ in C++ looks a lot like boost::range on steroids. This is very promising and I can't wait to try it. I am tired of wrting code with the STL algorithms which do not compose as nicely as LINQ and it is one of the things that I miss most when programming in C++ and not in C#.
What I do not get though, is why using C for Rx. Is it because the library that was wrapped was in C or is this a general decision? I doubt that people programming in C are really interested in Rx and using Rx in C seems to be very complicated. Why not doing all this in C++?
An Rx interface to the async stuff in WinRT might be an interesting showcase.
So why not offer C++ programmers the same possibilities?
What is the motivation? What are the technical reasons, if there are any?
I just want to elaborate a bit more about our motivation to support XP at least until 2014, maybe even longer with our software:
We are a manufacturer of measurement systems that are sold with an industrial PC (with Windows XP or Windows 7) and a sophisticated C++ application for acquiring, storing, analyzing the data.
Only recently we managed to offer Windows 7 64-Bit with all our systems because of driver issues of 3rd party data acquisition boards that are in the IPC.
We have an OEM license agreement with Microsoft for embedded systems that still allows us to purchase Windows XP.
We are selling maintenance agreements with our software and we have lots of systems on maintenance worldwide that are running Windows XP. Some of them are used in test lab or production environments that are not even connected to a network, so even the end of extended support of Windows XP in April 2014 will not force customers to migrate to Win 7. Upgrades to Windows 7 are difficult and expensive because hardware (because of the driver incompatibilities) with costs of several thousand of dollars (up to $15.000) has to be exchanged. The measurement hardware of the system is used typically for longer than 10 years, the IPCs are exchanged every 5-7 years.
On the other hand, I am very interested in using the latest Visual Studio and toolset for our software. In the past, we managed to migrate to the latest Visual Studio release typically within one year after the release of Visual Studio. We have a demanding application that makes heavy use of multitasking and multithreading. New features are developed with the latest language features and libraries. We are using lambdas, auto, PPL and ConCRT and agents library right now with VS 2010 SP1 in our product.
Not being able to use the latest toolset lets say in 2013 (because of Windows XP) would heavily impact this strategy. I expect that we have to support XP until at least 2015. So having no XP support in VS 11 comes way to early for us.
Now that the quest for $112 is over, I just want to support Raanen with his (off-topic) request for an explanation of why the CRT Windows XP support was dropped. When there is a compelling technical reason OK. When not, well, this impacts a lot of C++ developpers, so maybe you reconsider...
@rab36: The Visual Studio 11 Developer Preview supports targeting Windows XP via native C++ multi-targeting. You need to have either Visual Studio 2010 or the Windows SDK 7.1 installed. You can then select the approprite toolset for you project. This post describes it for Visual Studio 2010 but it's basically the same for Visual Studio 11:
Tony, thanks for the reply. I am aware of the fact, that I can use the VS 2010 toolset to create programs for Windows XP with VS 11. But as Dennis already mentioned I am loosing the VS 11 C++ 11 compiler (and C++ AMP by the way) when doing this.
Could you confirm that the VS 11 toolset will definitely not support Windows XP? Or are you still considering changing this for the final product?
I think this is a big topic for all C++ developers and clarifying this would help us planning.
Thanks for putting so much focus an C++, I really appreciate it. Having a C++ conference is a very good idea, I whish my company would let me go there (coming from Germany it would be quite expensive). Hoping for Channel 9 coverage of the conference.
You are right, C++/CLI is an option for this specific scenario. Nevertheless, a pure native possibility to publish (and consume) components with a stable ABI would be great. This is missing from C++ for a long time now and WinRT components with C++/CX could be a solution for it. It would enable component based architecture for applications with free choice of the programming languages.
With C++/CLI you are forced to create mixed moded assemblies and to pull in the .NET framework and GC even when you consume the components from native code. Moreover it is not as easy to use e.g. PPL and ConCRT in C++/CLI (you have to to do a lot of indirection using pImpl all over) as in the the WinRT components. Think about all the pin_ptrs, gcroot<> etc. you have to write. I think C++/CX feels more natural, because it is native.
But to have C++/CX availabe for metro style apps on Windows 8 only, is a big limitation. I must say, that I am a bit disappointed with the BUILD stuff in total. Metro, WinRT, XAML based UI for C++ and all that is great. And I think that PCs with Windows 8 will have a very good chance to get a huge share from the tablet / touch market beginning next year.
But I think many of us C++ programmers (very likely the vast majority) will continue to write desktop applications for traditional PCs (because I strongly believe that there will be a large class of applications that cannot be Metro style) and they will have to support Windows XP and Windows 7 for at least 5 years from now.
For a C++ renaissance on Windows a great UI / general native library (like WinRT for Metro is) to program desktop applications on Win XP and successors is still missing (like the .NET Framework and WPF is for managed applications). And when I have to continue to program against the Win32 library now and know that there is something much bettern than this, but I cannot use it, it is a bit frustrating.
Great episode, congratulations! For me having an ABI and metadata that can be used in managed and native languages is the most exciting news from BUILD. I think one of the most productive ways of writing applications today is mixing C#/.NET code for UI, networking, XML etc. and native C++ components for accessing hardware and doing the really performance critical stuff. One big argument for using C# over C++ are the new async and await keywords that make asynchronous programming so much easier, which is especially important for writing responsive UIs. We were using COM for the interface between these two worlds for years now. But writing COM with C++/ATL and handling all the deployment stuff and datatype conversion is no fun at all. C++/CX, WinRT and .winmd seems to make this a lot easier, also making asynchronous operations across the boundary possible. But for our applications we will have to support Windows XP and 7 for a long time to come. So my question is: is there a chance to use this stuff for non metro desktop applications on older OS? I do not want to use any WinRT stuff, just the ABI infrastructure and C++/CX. Bernd
thanks a lot for this lecture on dataflow patterns. For me it was very interesting to see, that the equation 1 agent = 1 thread does not necessarly hold when using call, transform, etc. to implement the agent. This is good news, because that was one of my main concerns when thinking about using the asynchronous agents library.
Wow, what a great pleasure being able to hear that inspiring conversation of these famous guys! Thanks a lot Charles, that saved my day. I am having a lot of books of them of on my shelf and I can only hope that there will be more conferences focused at C++ in the future. Lots of young people are starting to learn C++ and lots of the older ones need to learn the new language C++11 in effect is. Is any of these guys planning to write a book about modern C++11? Bernd