@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:
@Glen: I had a chance to ask Herb about that - Here is what he sent me:
"First, we definitely provide two ways to access WinRT from VC++:
·The C++/CX language extensions, which give arguably simpler syntax, and definitely give better optimization opportunities because the compiler is aware of more of what’s going on. The syntax is basically the same as C++/CLI which is already an Ecma standard (Ecma-372) produced mid last decade with the gracious help and input of a who’s-who of the ISO C++ committee, and that is already open so that any compiler vendor can freely implement it, and if ISO C++ or any other standard wants to incorporate any of it we are happy to support that – in fact, several features from C++/CLI and C++/CX, such as nullptr and enum class, have already been adopted into ISO C++ and are part of the new ISO C++11 standard.
·The WRL template library provides a library style that also works if you prefer that.
I would encourage you to try both, and see which you like best.
We support both in our compiler wherever WinRT is available. For other questions about where WinRT is available (e.g., in Metro vs. desktop apps) you need to ask the Windows team since they own that – but wherever they make it available, our compiler will support it.
As for the specific question about the C++CX model regarding why we chose ^ and ref new: Definitely please see section 3.3 of my paper A Design Rationale for C++/CLI. Many of the same considerations apply that I mentioned there, even though WinRT is definitely not .NET.
·Type system: It’s important to have clear and simple statements about the type system. Today in Standard C++, the type of a new-expression is a raw pointer (*). Likewise, it’s important to be able to say something like, “the type of a ref new-expression is a ^.”
·Distinguishing different conceptual heaps: It’s nice to be able to distinguish the WinRT allocation from native allocation (i.e., ref new vs. new) as they are conceptually different heaps. The difference may not be as big as “CLR heap vs. native heap” but they are different.
I’ve been asked several times, “why not just reuse ‘new T’ so that it returns a ^ if T is a WinRT type?” This has been tried; the original Managed Extensions binding C++ and .NET about 10 years ago did try to make “new T” simply do (and return) different things based on the kind of type T is. This turned out to be a bad idea for two main reasons:
·It was the primary source of design problems: We realized that many of the problems were actually secondary problems stemming from one primary problem, namely that this design conflated two things that should be independent: a) the kind of type; and b) how it’s allocated.
·It ran counter to Standard C++: Tying those two things together actually ran counter to today’s Standard C++, because Standard C++ already allows you to express different kinds of types (e.g., reference types having virtual functions, value types that are copyable, POD types which are bit-copyable) and makes it completely orthogonal where you can allocate them (e.g., any of them can be allocated on the stack, or as a directly embedded class member, or on the heap with new and managed with a raw pointer, or on the heap with make_shared and managed with a shared_ptr, and so forth). We felt it’s important to keep those things orthogonal.
@Glen: From reading both your parts it's still unclear to me what problems you see with using C++ & WRL? I don't believe there is anything you can do with the component extensions that you can't do with WRL so I'm wondering why WRL isn't a suitable answer for you.
Please see my replies to Artur & Hmm for language conformance and address that through updated release cadences.
@hmm: The reality is that schedules change as we progress towards RTM, sometimes you have to cut things and sometimes you get the ability to add things - This is why I can't gurantee what is in the product until it actually locks down for shipping.
That said, in my response to Artur I said we're not going to be in 100% conformance, we're not going to be equivalent with gcc in conformance. Are we going to be better than where we are today? Maybe, we're looking at what we can do about that.
We are currently investigating shipping the compiler and libraries at a faster cadence than VS - Is this going to happen? We don't know, we're just starting the work on it - Would this mean quicker delivery of additional language features? Yes - How much quicker? At this point we don't know.
@KMNY_a_ha: Artur - Thank you for the clarification, I completely understand the english as second (third, fourth, etc) language - Let's assume we've shaken hands and put that behind us.
I do want to ask you though to not feel shy about challenging anything we do say - I work closely with the rest of the team to ensure that everything we say is accurate and truthful so if it appeaars that we aren't doing that then please feel free to raise questions - As I've said before if there is every anything that you think we're doing that doesn't uphold that policy please contact me directly and I'll get it sorted out.
Onto your request - Thank you for the list of things that would help you - Your point about final/sealed is well made and think easily fixed - It's a little thing in terms of the list you provided but we're going to try and fix that for the Beta - I can't confirm that it's in until the work is fully done and we ship the bits but we'll try.
As Herb alluded to in our video we're going to try to change the way we deliver language features in our compiler - Again we can't be sure we can given the realities of our situation but we have heard you (both you and the community) asking for faster turn around on this and we're working to try and make that a reality. Right now all I can ask is for you to wait until after we get our beta out to start seeing that cadence change in release - Of course telling you we're trying to do something and doing it are 2 different things, which is why all I can do is to ask you to wait on that and consider the above.
The second set of questions you posed are around publishing to the store and for now those policies haven't been decided. When they're worked out the details will be published on the Building Windows 8 Blog - https://blogs.msdn.com/b/b8/
@KMNY_a_ha:Artur, Thank you for the long post on your reasons - I appreciate you taking the time to write that up for us.
Let me break this into 2 parts. The first is really just commentary on our actions as you have described, the second is where we can talk the specifics of what we can do in the product to better the situation.
I don't believe that at any time I have lied in answering comments here nor in any of the videos - Do we have a difference of opinion? Certainly we do - It's my opinion, and the opinion of the people I work with that we are committed to C++ - Your opinion is that we aren't - That's fine, we have a difference of opion, we're not lying to each other.
Now you may not be part of the group I highlighted with my comment but I stand behind the fact that, yes there are people who effectively believe that if we don't implement 100% of the language standard then we clearly don't care about C++. In this release and most likely the next we're not going to reach 100% conformance - Does this mean we don't care about the language? I don't believe so.
"Guys, we really do want to engage again with C++ community but for now in order to keep our position in the market we have to do x, y, z (without giving sensitive information of course). Guys, we will not have time to implement core features in next release of VS but please stay with us and we will do everything what's in our power to improve this situation ASAP."
I believe this is very close to what we've been doing and saying here - But this isn't a point worth sticking on - Let's just agree to disagree and move on.
As for stopping answering questions if I have missed completing a thread I'm more than happy to go back and answer that - Feel free to either post links to those threads here or send me email directly (tgoodhew) and I'll go back and post a public answer - If I have missed questions that is an oversight not a policy.
As an aside, on Raman's thread I have a couple of questions that I had posed to the team and intend to post back to that thread once I'm sure that I have the answers correct.
With that out of the way let's move on to:
The 2 compilers you use are ours and gcc - There is a gap in conformance between the 2 - We're working to try and close that but it would be valuable to know what the stack ranked order of this we could do to make the situation better.
If you could list the top 5 - 7 language features that would be important to you, in order of importance, what would they be? It's look something like this:
Range based for loop
But your actual language features not just the example I gave above.
@KMNY_a_ha: I'm curious about why you use our product? From your posts it seems fairly clear that you value a high degree of standards conformance and that you find our compiler lacking. It also seems clear that you're aware of GCC and the fact that it does a better job of delivering on conformance than ours.
So why are you using Visual C++?
I'm really interested in this - You're clearly passionate about conformance and angry at our product plans - Is this because you use different products during the day and by not delivering on conformance we're making it harder for you to maintain a core code model? Is it because you have some old Microsoft based codebase that you have to maintain and it annoys you that you can't use the language the way you do in GCC?
If you can take the time to explain why/how you use Visual C++ I think it'd do a lot for us to come to a better understanding.
@felix9: We're not at the stage in the product cycle where we are disclosing what features appear in what edition of Visual Studio but I can say that we will be aiming for consistentcy with all VS languages in the distribution of these features. What that means is that if an ALM feature is available for one language the same feature should be available for all languages in the same edition.
@schroedl: John - One of our PMs will follow-up using connect on this to find out what the issue is - Right now the suggestion is to the "Tools/Options/Projects and Solutions/Build and Run" settings and change the MSBuild log and output verbosity to "Diagnostic" and see what it says.