This looks very useful. Is this for managed code only? Or can I use some of the features for native C++ code, too?
Loading User Information from Channel 9
Something went wrong getting user information from Channel 9
Loading User Information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
|Coffeehouse||% of OS being used by business||31||Nov 22, 2011 at 10:47 AM|
|Coffeehouse||Development tool life cycle is different from the OS||21||Nov 22, 2011 at 10:27 AM|
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.
Windows XP extended support lasts until April 9th, 2014. VS 11 is supposed to be released in 2012, right? So why not supporting to create C++ programs for XP in VS 11 with the latest C++ toolset?
.NET 4.5 will very probably support Windows XP because it is an inplace upgrade from 4.0: http://reddevnews.com/blogs/rdn-express/2011/11/back-to-app-migrations-with-ms-net-vnext.aspx
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.
If this is not an appropriate thread for this question, what is? Where should I ask this question? Support for Windows XP is a make-it or break-it 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 Goodhew - Microsoft Corp.
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.
There seems to be evidence that VS 11 won't support creating C++ programs for Windows XP SP3 any more: https://connect.microsoft.com/VisualStudio/feedback/details/690617.
If this is really the case, it would be very important to know this as early as possible. Can you comment on this or investigate what is planned?
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.
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.