Snippets of the Metro style version for the most popular 101 application.
Download this Beta today:
As Jason Zander –CVP of Visual Studio- just confirmed, a Visual Studio 11 Beta was released earlier today.
What can C++ developers expect from this new version compared to Visual Studio 2010? Here's a summary:
For further information, these MSDN Library article dives deeper in these new features for Visual C++ developers.
Links of interest:
Can someone explain the rationale behind dropping support for Win2K3 and XP/SP3 in VC11 run times?
"Can someone explain the rationale behind dropping support for Win2K3 and XP/SP3 in VC11 run times?"
The only plausible/obvious reason:$$$$$$$$$$$$$$$$$$$$$$$$
Agreed with all of the above - lack of XP support is an absolute deal breaker.
I can point out one obvious thing that does not exist on XP: <condition_variable>. The imports from kernel32.dll will be missing. And there might be several like this.
Where is ATL::AtlGetCommCtrlVersion? I could not find it in VC++11.
The following is broken in VC++11.
WTL 8.1 include\atlapp.h line 602
HRESULT hRet = ATL::AtlGetCommCtrlVersion(&dwMajor, &dwMinor);
AtlGetCommCtrlVersion is on VC++10 VC\atlmfc\include\atlbase.h line 7505.
Why doesn't the new syntax coloring work in debug? Can I enable it somehow?
It would be nice if someone from the VC++ team tried to justify using APIs that are not available on XP for implementing the CRT. Of course new APIs = new functionality. However as you can see 99% of VC++ users need to support Windows XP.
There is minGW that supports more C++11 features and can be used to target XP. So Microsoft, what are you thinking??!!
How about fixing the error message: "Project file '' has been renamed or is no longer in the solution." before you release VS11 ?
Unicode string literals is so important to us, the utf-8 is more meaningful than utf-16 and utf-32.
Gabest: MSVC's implementation of condition_variable doesn't use the Vista-provided condition variables possibly since condition_variable_any would need to be written from scratch anyway, and SleepConditionVariableCS doesn't support absolute time waits. Granted, that last point seems a bit academic since the implementation of wait_until doesn't do absolute time waits (but it looks like that isn't actually strictly required by the standard for the _until fucntions?) and wait_for is briefly based on a non-steady clock (but steady_clock also isn't steady...).
STL: Is std::mem_fn no longer working with __stdcall functions also known? In particular, I had a usage of shared_ptr with a custom deleter of std::mem_fn(&IUnknown::Release). Or was that something that never should have worked in the first place?
Michael> MSVC's implementation of condition_variable doesn't use the Vista-provided condition variables
It's powered by ConcRT. In the future, I would like to power std::call_once() with Vista+'s Call Once API, but I won't have time to do that in VC11.
(To state something that should be obvious: I'm just a dev, I don't get to decide what VC's minimum supported platform is. The Powers That Be decide, then they tell devs like me, then the devs do whatever is necessary. If I want to call an API that exists on our minimum supported platform, whatever that is, I can do so unconditionally, otherwise I need conditional logic at runtime. The STL has very few OS/architecture/etc. dependencies so this rarely affects me anyways.)
> STL: Is std::mem_fn no longer working with __stdcall functions also known?
Yes, that's a known bug, tracked in our internal database by DevDiv#257251 "<functional>: Consolidated Omnibus Calling Convention Bug of 2011".
> In particular, I had a usage of shared_ptr with a custom deleter of std::mem_fn(&IUnknown::Release). Or was that something that never should have worked in the first place?
It should work (and the only reason it worked in VC10 is because I put a lot of effort into making it work). My intention is for <functional> to respect arbitrary calling conventions, including when the default calling convention is changed with /Gr or /Gz. Although I loathe custom calling conventions because they make my life miserable, they are somewhat common, and if they don't work with <functional> then that makes users miserable. (If I were World Controller, I would eliminate x86 support as soon as possible, which would have the convenient side effect of eliminating custom calling conventions.)
Unfortunately, as we changed our code to conform to C++11 and simulate variadic templates in a more convenient form, some of my calling convention hackery was damaged or lost. Restoring it will take a fair amount of work, and I've been busy with more urgent things.
As a workaround, you can use a lambda instead of mem_fn(). It'll be somewhat more typing, but it'll also be more efficient - the optimizer can't "see through" mem_fn(), whereas it can see through lambdas just fine.
In related news, we have made stateless lambdas omniconvertible to function pointers with arbitrary calling conventions, so if you've got an API expecting a __stdcall function pointer, you can give it a stateless lambda.
What's the committee's document that most accurately reflects the current <filesystem> header in VC++11?
www.open-std.org/.../n1975.html is the "Filesystem V2" interface that we're targeting for VC11. This has been revised to "Filesystem V3", but we didn't have time to pick up those changes for this release.
A workaround is available to get VC11 statically linked CRT and MFC applications to run on Windows XP.