Using the Windows Runtime from C++

Why can't Microsoft develop a normal, modern API for native languages without changing language standards?

Can't agree more with you on this. BTW GCC has better C++11 support, Qt is a modern API...

So they turned C++ into some retarded C# stepbrother?

i understand how this model can be good, and it would be if windows was the only platform we wanted to develop C++ on.
so basically if you want to develop for metro, your code wont be portable, even if you build some kind of multiplatform library (like QT) it just won work because of all those c++ extentions..

also they say that metro apps compile into x86 machine code (native code) like before but how can that be possible if the same build runs on x86 and ARM?
i still dont understand how "native" is the new metro platform, it looks more like a new .NET platform

+1. This is a major fail, IMO.

Instead of sticking with standard language and providing their extensions using libraries and metadata generation from these libraries so that we could see and maybe even change what's going on under the hood here (which should be one of the benefits of using C++, shouldn't it), they had to mess with the language itself to hide everything behind this auto-magic nonsense, leaving no option for the developer to change or optimize anything - typical Microsoft. If I wanted to be this insulated without an option to influence the mechanism that goes behind the scenes, I have plenty of high-level languages that already do that better. Also, imagine trying to use WinRT API from other C++ compilers...

I loved one thing he said:

"I seen people translating C# code into this literally line-by-line and that's something to be proud of".

Yeah, you could have just named this C# without MSIL and garbage collection then.

horrible

A new "incompatible with everything" platform which will be thrown away in a couple of years, like the "original" .NET platform has been thrown away.

Hey Microsoft, wake up!!

so why is talking a guy who is in the standard c++ comittee of weird windows specific .net like language extensions for c++ instead of proper c++11 implementation of windows api ?

don't get it

this bullshit will never be accepted by the c++ community

C++ is dead at Microsoft. I don't know what to call this language, but I certainly would not call it C++, it looks horrible. I develop for Windows, I have invested a lot into C++, but I guess I'm going to switch to C#, because I refuse to write in this stupid randomly invented language. Way to go, not implementing any C++11 features and ruining the language.

Will Herb Sutter be "the guy who killed C++" ?

I don't think C++ will die this easily. Not everyone is writing applications so that some lame hipsters can connect to twitter/facebook/insert_trendy_social_network_here and upload some crap pictures about their pathetic and worthless lives. Hell, even C is alive and doing well. On the other hand, it's kind of sad to see Herb introducing this ... I don't even know how to call it. The irony, though. A guy who's on the C++ standards board and is basically saying, "look, we've butchered C++ until we've turned it into a retarded brother of C#".

But you know what's most bothering ? The everywhere present and misleading "written in C++". I'm sorry, this is not C++. I'm pretty sure it's not the C++ that you talk about in your books, Herb. So why these slogans everywhere ? Why not just come straight and just say "hey, if you want to write metro apps you have to use our contraption" ?

After having watched the talk I cannot understand the negative tone of some comments so far.

On one hand the C++ community has been envying C# for the nice things they had like reflection, xml support and so on. And compare the slow standardizing process of C++ to the innovations in .NET, this has been ridiculous.

Now Microsoft pushes C++ forward and you still complain. I don't see this as being retarded, for me it is C++, it is native and fast - and the need for the managed environment and garbage collection is largely gone.

Until today we have been forced to use C++ for fast code and C# for the UI, and the glue code in between took up lots of resources (== money, == time). Now we can use C++/CX and the need to write this glue code is largely gone, and in addition it'll be all native and fast. I'm happy. I will be able to concentrate on code I *want* to write and not code I am *forced* to write.

I'm also happy that a lot of the things look familiar. The syntax of C++/CX is not far from C++/CLI, which I happend to know a bit. Many other concepts connected to metadata are very similar to what was known from C#, so no big departure from that also.

I would love if this would be supported in the desktop applications as well and not only in the Metro application world. I can't wait to play with the stuff.

I don't understand negative comments.

Finally, we'll be able to use C++ with XAML. And it's all native. Full speed, full power of C++. Language extensions? Welcome!


Good job guys.

Agree with Peter and dee here. Having done win C++ dev for the past 15 years with Win32, COM and MFC, and lately C++/CLI managed layers into Winforms and WPF, the XAML/C++ discussed here is a vast improvement. Fast, native C++ code directly behind declarative XAML, with a rich designer/developer workflow toolset - perfect.

Some language extensions for reflection - fine, big deal. Compared to COM code (ugh) or some other system (e.g. QT) for pseudo reflection its great, and easy to isolate from other portable C++ layers.

Appreciate MS's investment in preserving dev choice here.

Good work MS - love it.

There's way too much griping here... there's only one mainstream C++ GUI toolkit(gtkmm) that doesn't rely on hacks. You have to use Objective-C(C++) on OSX and with Qt you have to use the moc preprocessor.

That being said, it shouldn't be called C++... Maybe Sharpened C++

"i understand how this model can be good, and it would be if windows was the only platform we wanted to develop C++ on.
so basically if you want to develop for metro, your code wont be portable, even if you build some kind of multiplatform library (like QT) it just won work because of all those c++ extentions.."

Um, no... you can still write portable C++ code... just be careful where you use Microsoft's extensions.

The C++ component extensions Herb is talking about are interesting, but, frankly, if I had to choose between them and more complete support for true C++11 (which is something we desperately need and something the VS team just said they aren't going to improve much in the next version of VS), I would *absolutely*, *unquestionably* have chosen the latter.

I am a Windows guy, I develop client applications that are Windows-only. I have been doing this for years, I like it. Yet even I am wondering why is it that after all these years of talking about the importance of standards and being open, Microsoft *still* prefers working on their own proprietary extensions to everything at the cost of supporting standards.

Sigh.

We Fear Change!

lol. what's this? C#++?

Andre wrote:
>Why can't Microsoft develop a normal, modern API for
>native languages without changing language standards?

See 12:00. Partial transcript of what I said, and I agree it's important: "It would be a mistake, and we are absolutely not telling you, to go rush out and say, 'every class I ever wrote should now be a ref class or a value class and I shouldn't use those old standard things any more.' Not at all. Pish-tosh. What you should be doing is writing your C++ code, if that's the language of choice, just as you always have with absolutely no change."

You're right and we agree -- virtually all of your code should continue to be written in portable ISO Standard C++, including the many C++11 features in VS2010 and VS11 including lambdas, auto, decltype, move semantics / rvalue references, override, thread, mutex, future, shared_ptr, unordered_map, regex, and much more.

We completely agree that Standard C++ is what to use nearly all the time.

ONLY on the boundary, when Standard C++ types are not ABI-safe and can't talk to other Microsoft languages, use these extensions as a translation layer. That's all -- everywhere else, definitely, use Standard C++, it's great and we love it.

See also the opening 5 min or so of my second talk that I gave today (835, not online yet as I write this but should be online within 24 hours) for why we didn't implement more C++11 standard features in this release. Short answer: We intended to do that and made a serious effort, but got caught in a trap (sigh -- believe me, we're as frustrated about it as you are... really) and we will continue to implement C++11 features as quickly as we can, we continue to consider improving C++11 conformance as a Pri 1 feature for our team.

@Herb
Please answer this question: If I decide to write C++ GUI application in Metro style am I forced to use all these proprietary ref, sealed, ^, Platform::String^ extensions for GUI components or not? I am not interested in communicating with other MS languages.

If the answer is yes I Am still forced to use those then I am not interested in anything what WinRT offers to me and I hope somebody else (Qt) will come with Metro port which will let me continue to write my code in standard C++.

I also don't like you are calling it C++ although it's not standard C++. It's C++/CX. This is something I wouldn't expect from former C++ ISO chairman.

@Herb:

"We intended to do that and made a serious effort, but got caught in a trap (sigh -- believe me, we're as frustrated about it as you are... really) and we will continue to implement C++11 features as quickly as we can, we continue to consider improving C++11 conformance as a Pri 1 feature for our team."

Sorry, Herb, but we, C++ developers, have been hearing these promises that everything will get much better in the very near future for at least 5 years already (actually for longer than that, we have been hearing this from the moment .NET started and .NET is more than 9 years old), and we are tired of this.

It is very easy to say that you will "continue to implement C++11 features as quickly as you can". By saying this, you aren't promising much. In fact, you aren't promising anything. It is even easier to say that you will "continue to consider improving C++11 conformance" (oh, god, did it come to the point where we are supposed to be happy because you promise to continue "considering" something for C++? really??). Please forgive me for saying that, but this is just noise.

I am thoroughly disappointed in the priorities you've chosen for the next version of Visual C++. I am not fooled by the above attempt at damage control.

Herb, thanks for taking the time to reply and address some of the concerns raised. Based on this session's feedback and the 90-odd comments on Stephan's VC11 post on the vcblog, I think it's fair to say a huge majority of people are disappointed by the lack of C++11 language features in VC11.

That's not to belittle the great advancements in the IDE, C++11 Library conformance, ALM, C++ AMP, and so forth, but those things don't make up for the glaring lack of language features.

I also think it's disingenuous for Microsoft to make such a big deal about C++ at BUILD when in fact it's really just a proprietary, non-standard extension for building Metro apps. That has no relevance for me as a C++ (standard ISO) developer of Windows desktop software products.

@Guys

I believe there is way to create and consume WinRT components (at a lower level though) in standard C++ and it is called WRL.

Have a look here: Windows Kits\8.0\Include\winrt\wrl

@Tomas (and others)

Qt is NOT written in standard C++! It is grossly inconsistent to claim that and complain about non-standard extensions to VS11 C++ in the same post. Advantage of Qt is cross platform portability, but you still have to use preprocessor to make it digestible to a standard C++ compiler.

I don't like non-standard extensions just like the other man, but you don't have to use them for classic desktop apps with VS11 C++. Once you decide to go WinRT route, it almost becomes a moot point - the part of your code connected to the real world is not portable anyway.

Nice step on retooling the APIs for UI, I'm glad in use a more polished code and even better it is separated in model-view. Really, don't understand people high complaining, I can only imagine it is the fear of re-learning something but hey!, it is part of any development process, learning and use the right tool for the right job.

Waiting VS11 be available fridday for non-msdn-subscribber, already using it on Win8 for Dev (using msbuild in console for learning/testing the new C++11 additions)

I was hoping they'd follow the principles of STL like they did with the PPL. I'm not interested in Metro apps, I was really expecting something for the desktop as well(that would replace MFC). No serious C++ programmer will ever use these extensions, they totally ruin the language and the visual appearance of the syntax is also horrible.

Please consider postponing the release of VS and implementing C++11 features.

With .Net, P/Invoke and C++ translation was happening in C#/Vb side. This time it seems it is happening at c++ side.

.....at least in Syntax

all build conference videos speakers spam "native", "native", "its all native".
so if i understand correctly winrt is some kind of super modern advanced COM framework that can be called from all those languages. JS, C#, VB and C++/CX.
since C++ didnt support so many things like interfaces, properties, partial classes, etc they had to add all these extentions so it could call all those COM libraries that are part of winrt. is this correct?

also, since COM is native and .NET is reserved for the desktop, what does vb, js and c# compile to? native code as well? or do still wun on top of a virtual machine? if so, what machine is that, since .net is no longer on metro style (but remains on the desktop).

its all a matter of adapting, basically if you have a multiplatform application you write all your core code in standard c++11 (as much as the compiler support anyway..) and for the UI and operating system communication you use c++/cx (if you want to support metro). doesnt seem that bad, just use a few #if directives like shown on the talk and you can target your app for multiple os's, even tho you cant use the same multiplatform toolkit library anymore (you can but it wont support metro).

anyway theres good and bad changes, my only fear is that many developers start using c++/cx left and right (even when they dont have to) rendering so much code useless if not on a windows machine.
problem here is that TOO MANY developers in the world are windows only developers so they couldnt give a rats * if other developers cant re-use their code.. future will tell.

Alex,

There are ways to do this that should not require language extensions. You could use templates to signal interface relationship, you could use plain objects to map those things. You know what I would like to see instead of a "property keyword"? This:

template<class Getter, class Setter, class obj&> class property;

private:
string name_;

public:
property<() -> string { return objref; }, (string pname) { objref = pname; }, name> ;

Simple, non-intruse C++, adherent to the standards layout. We don't want new keywords. We don't want new symbols that have no meaning whatsoever.

Why can't Microsoft give us a:

std::smart_ptr<System::String>

instead of a:

System::String^

Since they are basically the same thing (a refcounted pointer to a System::String object)? Why introduce new syntax and semantic elements TO THE LANGUAGE instead of interfaces to the environment?

Sorry, but unless there is something really neat about WRL, Metro will fail just as .NET failed. Nobody will jump in this bandwagon and I'm sure everybody wants to leave Win32 behind as much as Microsoft, but nobody will do unless they do it right.

@Alex:

"basically if you have a multiplatform application you write all your core code in standard c++11 (as much as the compiler support anyway..) and for the UI and operating system communication you use c++/cx (if you want to support metro). doesnt seem that bad, ..."

I agree this isn't bad. What *is* bad is that this adds very little to what we can easily do without all these bells and whistles in the desktop mode of Windows 8 already (Metro-style UI? come on now, if you think we are going to port our UI-heavy application with hundreds of dialogs and thousands of commands to Metro, think again), *and*, worse, that the ability to write Metro apps apparently comes at the expense of support for new features of C++11. The latter thing *is* bad, and is an example of a downright horrible value judgement on part of Microsoft.

"problem here is that TOO MANY developers in the world are windows only developers so they couldnt give a rats * if other developers cant re-use their code.."

I agree. I also think there is a much worse problem here. Microsoft is known to widely promote various technologies, "bet the farm" so to speak, only to throw these technologies away after a short time. Take a look at .NET. At the beginning of .NET Microsoft promised to extend it to cover the entire Win32 and use .NET for literally everything. Did this happen? Absolutely not. Office is still unmanaged. Most of Windows is still unmanaged. The absolute most of large applications written outside of Microsoft are still unmanaged, and have no plans to become managed (in fact there are several examples of reverse conversions). Now these Microsoft guys have a new toy, WinRT. Will this go anywhere?? Who knows, but I sure as hell am not betting any farms on it. I know that very soon Microsoft will have a new toy and once that happens WinRT is going to be left in the dark. I am ready to bet the farm on C++11, because C++11 is a *standard* and, as such, is going to be supported by the entire industry. But WinRT? No, thanks, I'll pass.

@PaulJurczak
You are right Qt itself contains extensions to C++ language. It is adding reflection mechanism and slot & signals support, maybe some other stuff which I don't remember now. Many programmers are complaining about that in Nokia forums and suggest f.e. to use boost::signals to replace at least the slot&signals part. However this is still nothing when compared to how we have to change our code to write Metro apps.
When Herb Sutter announced C++AMP along with the new "restrict" keyword it all looked natural and well-thought because there obviously is a need for such feature.
Now the situation is different because MS comes with tons of extensions which they claim they need for WinRT but most of them are actually duplicit with another language feature or not needed and if there is really a need it would be much better to implement them on the library side. I don't see why we have delegates when we have std::function. I don't know why we have partial classes when we can solve the designer-generated-parts problem with simple inheritance. I don't see the need for generics when we have powerful templates. I don't know why to bother with ^% style pointers, interfaces, array<T^>^, Platform::String^ and so on. And you have to go through all this proprietary stuff when you want to write metro apps. If somebody says this is not crippling the language then I don't know what else it could be. And at the end they are so impudent to call it just C++. Even a small fraction from their extensions would be just impossible to pass through ISO C++ committee. Definitely bad day for C++ community.

heh, actually you are not 'forced' to use C++/CX for WinRT, its just the 'fast and fluid' way to do it.
If you prefer the hard way, look at your Program Files (x86)\Windows Kits\8.0\Include\winrt\ for winrt.h wrl.h roapi.h etc.

We don't need these C#-like extensions to access COM objects in C++. In C++ we always write more code than in C#. C++ programmers want to know what the code do so they can tune it or make it performant, C# programmers don't care.

We don't need delegates, partial classes, generics, or ^ pointers since C++ already knows how to do that. Why would we do it the CX/C# way?

C++ references a COM object with a * pointer or a smart pointer.

Hopefully there seems to be a new WRL C++ template library somewhere. Is there any documentation about it? Can we use it instead of CX?

"Why can't Microsoft develop a normal, modern API for native languages without changing language standards?"

^ this

Honestly, the language extensions for WinRT seem fairly harmless, and at least they're not being promoted as a "new language" (for a change).

But really, why is it necessary? Why couldn't the same have been done using smart pointers?

Why is this being advertised as "a projection into native C++", when it is not native C++? Why is WinRT being hailed as an API that integrates cleanly into every language, when it does not integrate into ISO C++?

On a less damning note, I'd love to hear Herb Sutter or some other VC++ guy explain, quite simply, "how do other compilers get in on the action?".

Say I'm writing a Windows application to be compiled with MingW; how does it interact with WinRT?

Or say I'm writing a cross-platform app. How do I design it so the Linux or Mac version will actually *compile*? How do I avoid the WinRT "boundary" code bleeding into the rest of the application?

For that matter, what if I'm building an application in VC2008; how does that call into WinRT?

If Microsoft has good answers to these questions, I have no problems with accepting these "optional" language extensions for convenience.

@Herb Sutter:
"ONLY on the boundary, when Standard C++ types are not ABI-safe and can't talk to other Microsoft languages, use these extensions as a translation layer. That's all -- everywhere else, definitely, use Standard C++, it's great and we love it."

But that doesn't answer the question of "why do we need proprietary language extensions for this?"
What'd be wrong with a `winptr<String>`?

What is it about WinRT that makes it fundamentally impossible to project the API into ISO C++? You've got move semantics, you've got lambdas, you could implement a very clean and simple-to-use smart pointer to wrap WinRT types.

(And why does Microsoft *claim* that the API is projected into C++, when it isn't, when I have to use a separate "boundary language" to interface with it? If Microsoft is really going to go this route, could we at least be honest, and remove C++ from the list of languages it which it projects cleanly into, following the language's own idioms and all that stuff?)

Herb, and VC++ team, I can live with these extensions, and I'm sure it's possible to structure your code so that only a few boundary classes have to be written in this way, but I am really disappointed at the negligent attitude displayed: the big fanfares and proud proclamations of how WinRT fits naturally into *every* language, and how important the "C++ renaissance" is to Microsoft, when, at the same time, **zero** effort was put into actually integrating WinRT into ISO C++.

I'm saddened that we have to write code in a proprietary "in-between" language in order for our C++ application to talk to Windows. It doesn't matter *how much* of our code has to be written in that language; a single line is too much. C# developers don't need to write "boundary" code in a separate language. C++ developers do.

And for no good reason. I've seen nothing so far that *couldn't* have been implemented with a few smart pointers and perhaps some template metaprogramming.

Can we at least get an answer to why this Yet Another C++" is deemed necessary?

But that's missing the point. According to Microsoft's marketing material, there's supposed to be a "fast and fluid" way to use WinRT from your language of choice.

What is the fast and fluid way to do it from ISO C++?

You feel very pessimistic. But it could have been worst for C++. There were other possible scenarios:

-> Metro app could have been limited to HTML/Silverlight like on WP7.

-> WinRT could have been exposed as a .NET library added to the CLR.

In those cases there would have been no other solution than using C++/CLI to build metro app in C++...

Then, I did not tried, but in theory, it is possible to write metro application using standard C++.

Why?

Because the interface of WinRT API is supposed to be COM. But is it true COM? There is some traces of possible modifications, like a midlrt tool. There is also new famous interface IInspectable that seems to more or less replace IDispatch. But you are probably free to use all the COM stuff the old way, by hand (CoCreateInstance and so on). But it sounds painfull, like COM was (At least for me)...

Perhaps the wrl of Yannick could be another solution.

I don't know what is in the header files of wrl, but it seems from the web that there have been some additions to "Win32", like a WinRTInitialize in combase.dll. Or a CreateImmersiveWindow in TWINAPI.DLL. Is it a Win32 like layer under WinRT? It is still pretty hard to find information about WinRT internals (Does WinRT rely on Win32/DirectX, ntdll, the kernel?) without installing windows 8...

I am with jalf. It appears that the fast and fluid way to use WinRT from an ISO C++ program involves forfeiting compatibility with ISO C++. This alone makes C++ second-class citizen compared to other languages (heck, can anyone believe that even JS is supported better than C++?), and the whole notion of "C++ renaissance" laughable.

Sorry, but it is not C++. Next time, pick a name that was not already taken. An extension to C++ is not C++. C++ is the language that is defined by the ISO standard. And accordingly to the ISO standard, all new keywords must start with __. I know you tried this before with Managed Extensions, but it's not an excuse to change the language again. In a proprietary way.

Today we have to explain EVERY TIME on discussion lists that C++/CLI is not C++. Now you created a new source of confusion.

@rt15:

Using low-level interfaces is, of course, possible. However, that's a far cry from the level of support other languages get. I won't say anything about "fast", but using low-level interfaces surely isn't "fluid".

@Herb,

any chance to get async/await functionality in C++/CX?

I'm really puzzled by this.

Creating a language extension should be far, way more laborious than handing over a library with call interfaces. Maybe Microsoft thought it was nice to avoid verbosity and such and thus developed these extensions...

However they failed to see that we DO NOT WANT such extensions, we want just a plain library with call interfaces. Why waste so much time and effort doing this?

If you couldn't hand us a library and the language extensions was the only way to give us access to Metro, then we want to know why, what's so special about it that couldn't be handed in a simple library?

@Homero

+1

WE DO NOT WANT TO USE THESE EXTENSIONS

What Microsoft has accomplished here:
1. Adding awful language extensions that no one wants to use.
2. Not implementing C++11 features that everyone was expecting.

Way to go. I hope the C++ team understands that if they deliver VC++ as it currently is it won't be accepted by the C++ developer community - they'll effectively limit their sales to those who use C#/VB.

Booooo- Hiss Can anyone in Redmond here the jeerz

Maybe a simpler question could be answered.

In the managed code world if I have 6 YUV HD DirectX surfaces and multiple DirectShow callbacks which feed my assembly language interpreters before I display them in realtime how would it fair when compared to C++? 

These surfaces also interact with hardware callbacks for outputing. The display of these surfaces need to be realtime as well.

The interface, buttons/bars/combo boxes etc., does not need to be high performance.

It would fantastic to get ease of creating a modern XAML front end with all its glitz and glamor to work with this kind of C++ high performance multi-threaded back half without effecting the realtime performance of the C++ code wouldn't it?

In PDC 2009 the Microsoft DirectShow persenter said that managed code is more than 2x as slow as C++. So you can only conclude that WinRT and all its glamour will be not be for high performance bits and there is not a good way of making stylish front ends without rolling your own. (which I think is sad)

Bob Ahh well maybe windows 9?

I think MS should make another lower level API library for developers who really wants to control everything natively (even it is MFC-like :));

The current one can be used by C# developer probably :).

Don't want to developer to look closely to the COM layer ? code is badly written over there :) ?

Handling XAML layer for developers is not what they want.

@hmm

there is probably a spec somewhere for the object layout and semantics of the WinRT interface. The tool to take a winmd file and generate an ISO C++ wrapper library (or better some assembler macros) to access that will probably require less characters of code than the text in the angry posts above.

Perhaps this tool even already exists, made by Microsoft.

Anyway, I have not read it yet, but here should be an starting article about bypassing the extension and use COM stuff directly.

http://www.interact-sw.co.uk/iangblog/2011/09/16/real-native-winrt

@jalf:

Cause its not C++ its C# with yet another syntax. Sad but true.

Maybe there is an easy way to close this discussion:

Do you MS-guys use these extensions in Windows 8 code?

If yes, then we will certainly have to reconsider our bad 1st impression about C++/CX, and admit we are wrong.

If no, then this C++/CX stuff will certainly join WPF (amongst others) in the trash can very soon.

Oh no, not again! I hoped C++.Net was dead for good, and MS seemed to signal they were finally going back to pure goodness of native (standard) C++. And what we see? -- the same managed abomination again, how many times will MS step on the same rakes to understand that C++ developers want none of it? (http://www.youtube.com/watch?v=NmNObROcBOo)

C++/CX is like C++/CLI, except that it compiles in native code.
C++/CLI failed with .NET failure, and C++/CX will probably be too.
With C++/CX bound tightly into visual studio, true C++ developers might have to abundant the whole visual studio completely, and look for alternative C++ compiler in the near future.

Herb, do you think you can make an assumption about how many developer hours it would take to get all the 'No's in C++11 feature table to be 'Yes'. Would be interesting to know.

Is there anything new for C++ when developing for desktop and not metro?

Do you think you guys can release some patches to add more C++11 support that are independent of the whole VS release cycle?

>>We do have variadic templates almost done, they just didn't fit into this release which is very disappointing (to you and to us), and we are looking at creative ways to ship this and other C++11 work sooner than our normal schedule

This is the best news I heard all day. I don't care too much about how C++ talks with WinRT. After all, any code which does that will never compile on anything else anyway, it doesn't matter if it does it by using compiler extensions, templates or ritualistic sacrifices... it will never run or even compile anywhere else, might as well be as proprietary as MS wants it to be. But the work I do on my non-WinRT-specific code is pure C++, and that IS intended to compile and run everywhere. Having to restrict that to a VS2010 level of C++11-goodness is a pretty limiting throwback and being stuck there for years to come just because MS can't keep up with other compiler vendors would make the touted C++-Renaissance and self-proclaimed commitment to standard C++ a complete farce.

Why have so many C++ developers troubles with layering their work? In fact, if there are conventional and extensions-powered ways to nativelly access WinRT, then there is more options. May be more C# developers can try such extensions than C++ ones. I understand this difficult era of changes, so to @Herb, dont worry but continue with C++11 as you want and be nice to us .NETers too

I haven't checked the details, but to me it seems like C++/CLI compiled to native code, not MSIL.

If Microsoft needed to plug in .NET-like interfaces of WinRT to C++, it's easier to do it in a .NET supported language of C++/CLI. It's certainly less laborious.

Thank you very much for the detailed clarifications. This answers my concerns.

I especially like this paragraph:

>there are real conveniences (cleaner code) and efficiencies
>(performance gains) from using compiler-understood extensions
>like C++/CX, which is why we went to the trouble of baking
>a CComPtr<T> into the language as T^... so my only
>recommendation/request would be that you give each a
>try and then use whichever you like best. Who knows,
>some people who hate extensions might just find after
>trying them side by side that they kinda prefer the
>language extensions after all

I'm confused by the Person example.

It looks like the ref class ultimately gets two references, before 1) falling out of scope and 2) the last reference is set to nullptr.

In the slide, the comment says that ~Person will be called when nullptr is assigned (0 references, call the destructor). However all the syntax used seems to be identical to C++/CLI - and if the code was C++/CLI then ~Person *may not* be called when it reaches 0 references - it depends on what the CLR GC's doing.

What happens if we write large bodies of code with these extensions in "native" mode with compiler based reference counting and deterministic object destruction and then "upgrade" and compile to CLR?

> However all the syntax used seems to be identical to C++/CLI

My mistake, "ref new" differentiates them.

> My mistake, "ref new" differentiates them.

Yes, there's no GC, that's why no gcnew

Funny how all the hater comments above have not apologised to Herb for flying off the handle without knowing the full story. It seems that one can (if they so please) code in standard iso c++ with no frilly extensions to the language! - Why doesnt everyone who took the time to comment here reply back knowing what they now know?

@Herb:

"We will absolutely continue to prioritize C++11 conformance. No waffling intended. [...] We (and I) are actively working on it, and I don't expect my saying so to change your mind now, but hopefully when I can say and show more in the future that will carry more weight."

Indeed yours saying so isn't changing anything. I mean it's nice that you took your time to reply, but, as I said, that's just words. We've been hearing these promises that everything will get much better very soon for years. Me, my colleagues and a lot of other people have been burned on your promises so many times we no longer trust you.

I urge you to add more support for C++11 into the next version of Visual Studio before it is shipped. If you think people will once again take your word that although the release version of vNext will have basically the same level of support for C++11 as VS2010, but you will fix everything "very soon, although we can't promise any dates", I think you are going to be disappointed.

I have to say that I've got rather big concerns with simple reference-counting smart pointers being built right into the language itself via one-character syntax extension, so it would be nice if you could clarify this point for me:

Using smart pointer classes in C++ can be somewhat tedious at times, that's true. However, hearing you talk about the benefits of such deep integration and how reference counting is automatically omitted when passing WinRT pointers/references around on the stack leads me to think that these references do not only look the same way they looked in C++/CLI, but are also about to be used in much the same way, being basically everywhere the object pointed to is ever about to be used.

However, the one thing that clearly has changed from C++/CLI to C++/CX is the fact that in the latter there is absolutely no way of a garbage collector running in the background and checking entire reference graphs for being rooted. So it seems that circular referencing, bound to arise from the hierarchical nature of user interfaces, might be quite a big issue in C++/CX.

While the somewhat verbose syntax of smart pointers in pure C++ forces you to think about ownership in some way or other, at least requiring you to choose between strong referencing, weak referencing and perhaps even no referencing at all, ownership does not seem to be a question in C++/CX at all.

So summed up, my question is, how do you ensure that simple circular parent/child referencing does not lead to memory and resources inevitably leaking in every other spot of every program about to be ever written using these new smart pointer language extensions?

I really don't understand all the hate for C++/CX. If you're a cross-platform developer, you're already writing all your core logic in standard ISO C++. Herb recommends it in his presentation. The only time you would ever have to touch C++/CX is for the UI layer in *Metro* apps. This separation of presentation code from logic is good practice anyway and any cross platform application is *already doing this*, whether you have a Win32, Metro/CX or Objective C presentation layer.

Secondly, if you're making a desktop app for Win8, you won't be using CX anyway. This is only for Metro style apps. And if you're at all serious in any way about making a *touch first* app for tablets, you're not going to be porting your mouse and keyboard app as is. That's why iOS beat desktop Windows on tablets. Tablet users want a touch-optimised experience. You'll likely start the UI layer from scratch to optimise for touch, and continue to reuse your standard ISO C++ core for the logic.

@jinushaun:

These negative comments here are also influenced by the blog post that basically says "hey we didn't implement any new C++11 features".

C++11 features were not implemented, C# went from 4.0 to 5.0.

No modern APIs for C++ developers on desktop, .NET went from 4.0 to 4.5.

Also, it's funny that everywhere where Microsoft lists it's languages C# and VB are before C++. I'd expect them to be ordered alphabetically, but everywhere in text documents/websites they put C++ last.

I wonder why all C++ developers complain about a language extension, which is bound to a proprietary Windows runtime anyways? C++ doesn't define an ABI, Windows does.
Instead of complaining about these extensions, I would rather know how an object oriented Windows API should be defined in standard C++, which can be used from other languages and different C++ compilers.


Simple example: C++ compiler #1 is passing a std::string to another Dll compiled with C++ compiler #2.

Compiler #2 clears the string and the memory is freed by a different runtime - booom.
A runtime, which supports all languages, would be the least common denominator of all languages - simple function binding.

If all Windows developers would be C++ developers it would be fairly simple - WinRT would be something like QT - but come on - it's not the case. I don't know if I like WinRT or not. For a good statement if I like it or not I have to evaluate it more deeply and play around with it, instead of looking at the source code and complaining that it's not standard ISO C++. I'm not that religious about standard conformance or about the language I use.
I'll try to separate my code anyways: standard C++ code which is platform independent and other GUI centric code, which isn't necessarily written in C++.

C++ IMHO isn't a good language for GUI applications anyways, since it's hard to parse for all tools involved.
I like to see it that Microsoft tries to give us C++ developers the same development experience and support
as other languages. Just for that taking the risk to try it, thank you Microsoft - and thank you to support clean standard C++ through winrt.h too, as an alternative.


I'm more concerned about the implications regarding compatibility between Windows7 and Windows8.
If I want to use the new WinRT (the non GUI related part), I won't be able to use the same code base for Windows7 and Windows8. I think most business developers will continue to use Win32, besides Metro apps written exclusively for Windows8. Which will degrade WinRT to be an exclusive option for Metro apps only.

Anyways, I'm open to new technologies and will have a look at all the new stuff.

And a final thank you to the C++ team. I'm very happy to see that the implementation of C++ WinRT event handlers is now placed in a Cpp unit, instead of placing everything in a single header file, as it was the case in C++/CLI - yippee ;-)

Andre wrote

> If all Windows developers would be C++ developers
> it would be fairly simple - WinRT would be something
> like QT - but come on - it's not the case

I'm thinking about Gdiplus API, which is pure C++ API in native code:

using namespace Gdiplus;
Bitmap *b = new Bitmap("a.jpg");

and is also part of the .Net framework, can be used in C# or VB:

using System.Drawing
Dim b As New Bitmap("a.jpb")

This is the kind of API what I would have liked for WinRT.

This is not COM ABI.

Impossible because of concurrency/process/thread safety?

Two concrete suggestions:

1) Improve http://msdn.microsoft.com/en-us/library/windows/apps/hh454076(v=VS.85).aspx">http://msdn.microsoft.com/en-us/library/windows/apps/hh454076(v=VS.85).aspx

with an example that shows mostly standard c++11 code, and then only a few lines of code that interface with the WinRT interface.

WHY: People like to feel comfortable by understanding most of what a program does, and then add to their understanding with something new.  

2) Bundle all the explanations together and send a comprehensive document to everyone who uses Visual C++.   It should have a FAQ that addresses the various concerns present in comments.

I am not at all impressed with WinRT in general and C++ component extensions in particular. I am deeply disappointed that you have chosen to spend your time on these things instead of C++11.

It's quite sad to see that all the hype of C++ renaissance boil down to this.

> See my other talk on Modern ISO C++ which answers this for std::shared_ptr and std::weak_ptr, and why such circular references are pretty much always a wrong design in the first place (example: how often is it ever semantically correct for A to own B and control its lifetime, and B to own A and control its lifetime?). It's exactly the same issue: In WinRT, the analog for shared_ptr is ^, and for weak_ptr is IWeakReference.

@hsutter: Thank you for pointing me to IWeakReference, so it is possible to resolve these issues. This was actually my point exactly, it clearly IS bad design to have both objects control each other's lifetimes, however, coming from a managed or even from a C++/CLI mixed background, it would not actually seem like bad design to simply make use of C++/CX ^ handles for all ref classes, looking just like innocent pointers / CLI GC handles.
With objects no longer being moved around, it might even become viable to mix ^ handles with * pointers to the same ref class objects depending on reference/ownership semantics.

Given Herb's presence in the field I suggest we at least give him the benefit of the doubt... I am a bit suspicious of all these new bells and whistles myself, but I will take the time to play around with the new toys before I make up my mind.

I would be interested to see for example how generics map to native C++. If everything is kocher and purely for notational convenience there might be something worthwile there and maybe we should be more open with something that is largely platform specific anyways (and so is COM in general really, or are people doing COM without ATL or the MS COM extensions?!)

IMHO the whole Metro style apps business is purely a mobile industry related political move by MS, I am surprised they expect the whole desktop world to just convert! But the C++ dev in me is happy to be included in the latest MS trend for once (as long as you aren't trying to trick me into going managed!)

I can't cope with all these comments. Are these people actually developing for Windows? I seriously doubt so. I think most of them don't even develop in C++ at all, just here to bash MS.

These extensions are
1. Awesome as they are (well, some of them, but you can almost completely disregard what you don't like).
2. Easy to learn (I estimate 1-2 days at most for any semi-decent C++ developer) to use classes that expose them. Even if you don't like them.
3. If you don't want to learn how to write those classes, you don't have to do that at all.


Microsoft and Sutter did an awesome job here.

I hope you won't let these trolls fool you.

It's not the language extensions that people have problem with.
It's Microsoft.
After 15 years, despite of all that happened since, it's still a fashion for a huge community of people to blame MS for whatever they do.
Just ignore them, move forward, and let it flourish. They'll still hate MS no matter what, but hey who cares when 95% of people use applications that run on the top of this.

Is ^ really necessary? Can't the compiler just treat any declaration using a ref class type as a strong pointer? Personally, I think ^ is fugly. It just looks "wrong" compared to * and &.

Will I have the classic win32 in Windows 8 ?

Is the performance for Direct3D application better or worse using Metro v.s. win32, does this relation remains valid in windowed mode v.s. full-screen mode ?

Is the Metro interface available for other Windows versions like Vista,7 or Xp, or do I have to write many versions of the same application ?

pierremf wrote:

>I'm thinking about Gdiplus API, which is pure C++ API in native code:
> ...
>using namespace Gdiplus;
>Bitmap *b = new Bitmap("a.jpg");

Agreed - gdiplus is nice.
But how can such an object directly be allocated in a different language and then passed to C++, where the C++ application calls "delete b"?
And how does the C++ application know, that it can securely delete the object, because it isn't used anymore at another location? Besides, that it can't be deleted using a C++ syntax directly, without wrapping it and calling flat functions.

I think Gdiplus is an example of what I meant: "would be the least common denominator of all languages".
It's basically a C++ wrapper around flat functions, passing object pointers as handles.

And how should event handlers or properties been implemented independently from a language, when the language itself doesn't support properties or doesn't support event handlers (method pointers) in the language but "only" in a library, which can't be ABI compatible with other languages.

> ...
>Impossible because of concurrency/process/thread safety?

Not impossible, but perhaps impractical or reduced to wrappers around flat functions, without supporting needed features like automatic memory handling accross different languages, properties, event handlers etc.

In the end we would have wrapper frameworks for C++, for VB for C# for Delphi, which aren't part of the operating system.
Same as today: MFC, .NET, VCL etc. - all wrappers around Win32


As I wrote, if everything would be written in C++ it would be simple.

@Luckless:

"It's not the language extensions that people have problem with. It's Microsoft."

Speaking for me and my team, it's not the language extensions that we have problem with. It's the lack of support for C++11, and that Microsoft have chosen to work on these language extensions, which are of very little use to us, instead of C++11, which to us is *much* more important.

We are a Windows-only shop, just so you know, and have been for more than 10 years.

Please don't be so quick to dismiss us as trolls.

@PFYB: "Microsoft have chosen to work on these language extensions, which are of very little use to us, instead of C++11, which to us is *much* more important."

You're assuming that the same people who worked on C++/CX would have worked on C++11 instead.

@John:

"You're assuming that the same people who worked on C++/CX would have worked on C++11 instead."

Indeed.

You are correct that I don't know for sure if those same people who worked on C++/CX could have worked on C++11, but, quite frankly, this doesn't matter. Suppose they couldn't. Who could, then? Did Microsoft have people who could have worked on C++11? If yes, I am disappointed that these people have evidently been put to work on something else (what exactly was deemed more important than C++11? that's some terrible value judgement). If no, well, I am disappointed that Microsoft didn't (doesn't?) have the required talent to push C++ forward. Choose your poison.

PFYB,

I'm also very unhappy that VC2012 won't be fully C++11 compliant. Microsoft made a choice not to do it, and is fully deserving of the opprobrium being heaped upon them as a result. My point is that C++/CX shouldn't be singled out as the reason. If C++/CX didn't exist, the resources might have been devoted to Excel or SQL Server instead.

I expect VC2012 will provide a level of C++11 compliance that satisfies *most* customers. The problem is that *some* customers want full compliance. It sucks to be in that group. IMHO, a lot of the vitriol in the comments is driven by VC++ being the only game in town. There are no *viable* alternatives for *professional* Windows developers. We have to use whatever Microsoft chooses to give us, and nobody enjoys being in that position.

Andre wrote:

Agreed - gdiplus is nice. [..]
But it can't be deleted using a C++ syntax directly, without wrapping it and calling flat functions.
I think Gdiplus is an example of what I meant: "would be the least common denominator of all languages".
It's basically a C++ wrapper around flat functions, passing object pointers as handles.

No, you are wrong.

You delete gdiplus objects with C++ delete keyword. You call methods with "->" or ".". You can allocate objects on the heap or on the stack, and objects are automatically deleted on function return, etc. Gdiplus also supports inheritance: Bitmap derives from Image for example. Gdi+ seems very much like a C++ class!

Gdi+ is not "passing object pointers as handles" at all.

Hence my question again, why not using this kind of interface?

But how can such an object directly be allocated in a different language and then passed to C++, where the C++ application calls "delete b"?

Well, you can't C++ delete a GDI+ object allocated in C#, but how often do you need to do that? Once or twice in a lifetime?

I haven't needed that yet, although I use C#, C++ and C++/CLI, and have used GDI+ quite a lot.

Hello Herb,
what I didn't get from all of those session videos is the following:

Can an ARM based tabled show the normal desktop in Windows 8?

And if it can, will it be possible for developers to run native, classic MFC applications on an ARM based device with Windows 8?

I wonder why no other MFC developers (which still have a large base in business software segment) ask about MFC improvements in VC11?!

I'm looking forward to your answer, Greetings, Moritz

winRT == COM++

I'm glad that my c++/cli skills haven't gone to waste. ^s off to the winRT team!

Events and Delegates? Does that mean that c++/cx might support LINQ and Rx in the future? Rx's subscribe/unsubsribe model seems like a better way to use events.

I think this will only drive any remaining Windows C++ developers to C#/VB/ and maybe even JavaScript.   This is just too ugly and non standard.  I agree with others just get the standard done first so we can use C++ for non Metro apps.    The criticism stated here is valid and Microsoft should pay attention.

I hate to be a killjoy, but thats not C++ herbs other talk covers the 'real' C++,
this is what I call "C++/CLI" or more precisely C++.NET.

Still C++0x is pretty cool, got to give it to the developers.

Keep up the good work.

I'm wondering how generics is implemented in WinRT. On .Net you have this MSIL that gets re-JITed for each generic type with a value type argument on demand. How is this done with native code in WinRT?

Oh I got it. You can't define generic classes, but you can implement a generic interface with a class template.

So this is yet another difference between CX and CLI, should've mentioned this during the Q&A Herb...

To all the people that say Qt relies on C++ extensions, you are wrong: Qt code is 100% perfect valid C++ code, since Qt doesn't extend C++, it merely provides macros that another tool reads to generate some code. There are no compiler alterations for Qt.

Where is the WRL documentation? are we supposed to grep manually through headers? isn't WRL going to have first-class support by Microsoft?

Here is a link to some official lower level documentation. I don't know if it is WRL though, but it really seems to.

http://msdn.microsoft.com/en-us/library/hh309536%28VS.85%29.aspx

From some other persons investigations, it really seems that WinRT is currently built over Win32. Combase.dll and others rely on user32.dll and other classical libraries (MinWin is mentioned). The window that contains metro application is a classical win32 window. DirectX is probably used to draw controls in it.

It is funny that technically, WinRT really looks like FireMonkey from embarcadero: an UI library based on DirectX/Win32.

i prefer 'Real Native WinRT Development' than the extentions, C++ develpers always want to know what exactly happend undercovers. please MS do not make a new c## langue.

pierremf wrote:

>No, you are wrong.
Am I ;-)?

>You delete gdiplus objects with C++ delete keyword.

Agreed, but you call it on a wrapper.
And the base class GdiplusBase has a "operator delete" function implemented calling
GdipFree(...) and the destructor of image calls GdipDisposeImage(nativeImage);

>You call methods with "->" or ".".
>You can allocate objects on the heap or on the stack, and objects are automatically deleted on function return, etc.

Yes, once again from a wrapper.

>Gdiplus also supports inheritance: Bitmap derives from Image for example. Gdi+ seems very much like a C++ class!

A wrapper derives from a wrapper. No problem.
Have a look at the implementation of the Bitmap constructor:

It calls GdipCreateBitmapFromScan0. A flat function and stores the handle returned in the Image base class.

>Gdi+ is not "passing object pointers as handles" at all.


Sure it does. How otherwise could you use Gdiplus implementation code in gdiplus.dll from different C++ compilers, which have all a different ABI? Windows7 only supports either function based linkage or interfaces.
An option for Microsoft would be to ship the whole source code of gdiplus.dll and then a C++ developer could use it directly. But currently it's shipped as a Dll, where only flat functions can be called.
WinRT in this regard is different.

>Hence my question again, why not using this kind of interface?

It's based on a flat function interface, wrapped by C++ classes.
But as I wrote some essential points are missing. I'm too busy so I couldn't have a deep look at WinRT if it supports things like asynchronous GUI events, properties etc. - but I suppose it does.

What I already know is that WinRT objects, defined in any language supporting WinRT can be used natively by any other language supporting it too, without dealing with header files import libraries etc.
Besides the syntax, to which I have to get used to, I think it's a dream regarding language interoperation. Some kind of native .NET - at least I understand it so far, but may be I'm wrong - hopefully not.

But how can such an object directly be allocated in a different language and then passed to C++, where the C++ application calls "delete b"?

>Well, you can't C++ delete a GDI+ object allocated in C#, but how often do you need to do that? Once or twice in a >lifetime?

Sure - you could use the native handle and pass it to C# and then destroy it via the flat function.
Downside: You would have to manually set the handle to NULL and destroy the wrapper object.

But, yes, you can't destroy the C++ object directly, if you don't support a wrapper function doing that.

>I haven't needed that yet, although I use C#, C++ and C++/CLI, and have used GDI+ quite a lot.

But how do you call your C++ objects in C# or vice versa?
With WinRT, as I understand it, you can do that directly.
The only downside in C++ is, that you have to use a syntax like C++/CLI, but at least it's all native code.

Hello Herb,

> virtually all of your code should continue to be written in portable ISO Standard C++, including the many C++11 features in VS2010 and VS11

I believe you misspelled "GCC".  The VC++11 compliance status is underwhelming (except for concurrency support, which is a welcome exception).

> I don't have a specific estimate, but we are taking stock of this again and what's especially interesting is features that are low-cost (low-hanging fruit like final) and/or high-value (including features with lots of customer requests like variadic templates). Of course, we want them all, but everyone wants to see the "good parts" sooner so this comment is only about in what order to implement C++ features, not about which ones to implement.

Having a target date is important, as it shows commitment.  We all understand that schedules can slip but saying that you plan to be feature-complete by 201X will restore confidence.

Best regards,
Alex.

axilmar1 wrote:
> To all the people that say Qt relies on C++ extensions, you are wrong: Qt code is 100% perfect valid C++ code, since Qt doesn't extend C++, it merely provides macros that another tool reads to generate some code. There are no compiler alterations for Qt.

If Qt code was 100% perfect valid C++, then it would compile in a conforming C++ compiler. It doesn't.

What difference does it make if the extensions are handled by a preprocessor that runs before the C++ preprocessor and compiler, or if the extensions are built into the compiler itself? They're still extensions, and you can't run them through a C++ compiler.

3 days ago

Funny how all the hater comments above have not apologised to Herb for flying off the handle without knowing the full story. It seems that one can (if they so please) code in standard iso c++ with no frilly extensions to the language! - Why doesnt everyone who took the time to comment here reply back knowing what they now know?

Why? Because we all heard this story before. WHY does MS choose to shove everyone into slower managed code?

SLOWER as stated by the developer from the DirectShow group who stated its as much as 2x slower. Slower just from a common sense perspective, an INT does not need to be converted to string all day long and does not need to be an OBJECT. The time wasted to allocate, manage memory and garbage collect is overhead that has made Visual Studio 10 fat slow and unsuable on embeded PC's.

C++ was not created to be managed. It was a comprimise between using Assmebly and C, on the low end and Java, VB,.NET or C# on the FAT slow end.

C++ people were hopeful for some new standardized interface tools that could be used to pretty up a C++ presentation. What we got was, fat code and accept the new managed C++ order.

From this new managed direction a C++ coder might as well program Android with Java or go to Objective C++. YES, MS does find itself in a pickle doesnt it?

Programmers see hardware and software choices springing up and Windows 8 is a year away. In that years time Droidx86 will be on version 3 or 4 and Windows 8 will be on version 1 and who knows where Mac will be. LOL..

What kind of advantage does Windows 8 give the C++ guy really? Managed code? Thats an advantage? Heck Java has been managed for quite some time and the performance has always been mediocre. That slow start up with .NET application as it loads its 100 or so DLL's or whacky single threaded UI in winforms/WPF is why people don't like to be managed.

Here is MY windows 8 MS suggestion..

1) DROP this managed C++ into the trash where it belongs.

2) Give us a function that we call to load a XAML interface file.

3) In that XAML load give us a call back that execute the necessary interface hooks (sounds like windows 3.1 doesnt it) 

4) Give us a post message/send message way to fill these controls.

Lastly  most importantly LEAVE C++ alone to be faster and best at delivering time senstive information. We dont want to be managed.. We want to be as close to the metal as we can be. We can manage our own threads and memory and create out own objects, thank you very much..

Herb, is it true that WinRT applications will only be accessible through the Windows Store?

Hi there @ChicagoBob.

I think you are confused. At first I thought the same. I saw the hat symbol (^) and immediatly thought C++/CLI but its not. Its not calling through to a managed layer. They look like C++/CLI.. They smell like them but they are NOT. If you use them they compile out to standard native C++!

These new extensions (named C++/CX) just provide you with a higher level experience.


The WinRT is NOT managed - it is native, is built on C++ and is based on COM. Its COM version 2 if you like. When using C++/CX you are making COM calls and the syntatic sugar Microsoft have added just takes awya the uglyness of COM. You can though, if you wish target the WinRT using the WRL which is an ATL-ish template library.

Again... C++/CX is native. Its not Managed. for more info please check here:

http://msdn.microsoft.com/en-us/library/windows/apps/hh454076%28v=VS.85%29.aspx


Now, if you dont like the new language extensions no one is making you use them and if thats the case you can target the Windows Runtime using the COM wrapper library WRL (which is an ATL-like template library).

For me though ChicagoBob I wouldnt wish that pain on anyone!

Lol Herb, it seems you have made a classic text-book C++ mistake on the slide at 22:00. Can you spot it? ;)

I loved this sessions!  I don't know what all of the negative comments are about.  I think what Microsoft has done to allow developers to easily integrate with WinRT and take advantage of everything it has to offer easily and efficiently instead of having to write a ton of mundane code to get the job done.  Great job Herb!  You have excellent presentation skills as well.

Is this a joke or what? Herb you're a clever guy but that doesn't mean you're right. The boundaries/edges are a mess. The whole C++ renaissance according to MS rules is all utter bullshit. We want better tools, we want "real" C++11.

It's very unfortunate that MS choosed to extend the compiler with C#-ish syntax instead of delivering all or most of WinRT core support as a library. There might be some C++ developers who don't mind because they are already familiar with C++/CLI syntax but apparently there are many of us who will hardly feel comfortable in this kind of environment.

As for the WRL library I don't think it can change anything. I expect all MS tools like XAML designer to generate CX-compatible code, not WRL-compatible. Second reason is that WRL code looks like your grandfather's COM - look f.e. here: http://code.msdn.microsoft.com/windowsapps/DirectX-Marble-Maze-Game-e4806345/sourcecode?fileId=43833&pathId=1814339653. Every call to the interface is wrapped with DX::ThrowIfFailed and return value is passed in the last parameter. I think we can do better with C++11.

To me it looks more like if MS wanted to please .NET developers and ease them the transition to the C++ world because performance of your app matters. Being a C++ (not CLI) developer I don't see anything compelling about WinRT.

@flippster:

After a couple of days of watching video's I think I get it now. To be honest if

WinRT is managed or not doesn't matter. They created a COM interface for C++ people to use but added a lot of the CLI type syntax to deal with the new WinRT code.

It sure seems like the wrong choice for C++ guys, but thats me being stubborn. What I am now trying to figure out is how with HWNDs, HDC's and lots of old code can we integrate that onto a WinRT Canvas? Window? Whatever they call it. Also are numbers passed back via Object version of int? or an actual int? And... String handling. When you use devices they use lots of fixed char arrays to send text back and forth. Even SQL DB's have fixed field lengths. How do we interchange the String Object data with the fixed char arrays and vise versa.

To be quite honest it seems like a LOT of waste just to add cooler interface widgets, but thats just me being stubborn.

@Herb

Two things...

First, lack of C++11 language progress since VC10 is hard to forgive when your own polls show customers want C++11 by a margin of over 4 to 1 over anything else. Proof:
http://visualstudio.uservoice.com/forums/121579-visual-studio/category/30937-c-

Second, Microsoft has been deceitful and self servingly in remaining silent for so long, until Build - except to hype a "C++" "renaissance" - in order to spring WinRT and code samples on us and labeled it as "C++" when infact they are something quite different! - C++/CX. Cut out cutting it out!

When /CX is just 3 characters long, nothing excuses the *choice* Microsoft made to omit /CX from most if not all of the slides I have seen. It is clear deceit. Proof:
http://www.zdnet.com/blog/microsoft/heres-the-one-microsoft-windows-8-slide-that-everyone-wants-to-redo/10736

When you know Bjarne and a large body of other well meaning people have previously shown a distaste for this presentation style, it is clear Microsoft *chooses* to ignore that view and invite confusion and anger instead.

Evidence of the confusion is shown in the comments to this very blog.

Evidence of the distaste for Microsofts presentation style is here:
http://www2.research.att.com/~bs/bs_faq.html
Search for "What do you think of C++/CLI?". The principle is the same IMHO for C++/CX.

When you combine all this, the actions and the history; Microsofts one/two sucker punch style continues to smack of disrespect, deceit and some irony.

* The first punch is not implementing more of C++11 since VC10 - it shows MICROSOFT AGAIN DISRESPECTING THE PRIORITIES OF ITS CUSTOMERS while holding them back from using C++11 features in the products of competitors such as Clang, GCC, and IBM, etc. All companies WHO HAVE RESPECTED THEIR customers priorities by implementing more of C++11 quickly. Customers are leaving Microsoft over this style and others will when they can.

* In the second punch, that adds insult to injury - the deceit in presentation allowed Microsoft to pitch itself and WinRT as champions of a "C++" "renaissance" throughout and before the Build conference. When all the while, the reality was this:

* to consume any reasonable body of WinRT code *at all*, one must write - and tools will spread more of it - significant bodies of code that will exaclty be NON ISO C++ compliant - just more proprietary C++/CX!

In summary, how can we not find it *galling* to see Microsoft championing itself as the "C++" "renaissance" heroes while their priorities have been to hold back ISO C++11 conformant code adoption compared to their competitors; whilst actually speeding up the spread and adoption of NON ISO code through their tools and libraries. Code that will infect every other code base it becomes part of!!

The cold reality of all of this though is this: To consume or create any WinRT interface, one must either:

#1 write ISO C++ COM code that is SO UGLY THAT IT IS NOT VIABLE, which is why COM died the first time beyond MS use!
OR
#2 one MUST WRITE NON STANDARD C++ AT EVERY TURN to consume or create ANY WinRT style interface or use or share ANY C++ class at all realistically.

The scope of this is potentially everything! Given #1 is not viable, that leaves only option #2.

Option #2 locks peopple into Microsoft's walled garden. Also, no other current compiler understands C++/CX code that I know of. If they exist, they will be rare for years to come and will never come to some platforms.

Finally:

Herb, the argument that C++/CX should only be used at the "edges" borders on dishonestly in its simplicity when you know your tools will be used the most; and when they generate rafts of non compliant code all over the place! It's like letting a red ants nest into a black one and saying the traffic should be manageable!! What a pun!

Nor is it realistic the average Joe will use C++/CX at the edges either. That kind of discipline is understandably beyond many in a world of tight deadlines and bad designs.

So use of WinRT ^'s, will be the only viable option for so much code. Code that will lock out use of other current compilers and lock one in to MS for now. This is exactly what ISO standards are about preventing. Where's the C++ renaissance in that? It's more a "native renaissance" at best. C++ was never native nor managed IMHO, it was another Microsoft false choice. Conceivably C++ is both, whatever you compile it as.

So all in all, Microsoft has managed to engineer a situation that takes from open standards - standing on C++'s shoulders to get back native performance for Windows - whilst leashing C++'s neck to the same walled Microsoft garden.

So all these years later, Herb, for now, you will understand if I say:
"you seem like nice guy, but stop slapping me about!"

http://channel9.msdn.com/posts/Talkin-C-with-Boris-Jabes-C-Intellisense-Game-Development-and-Boris-Faces-His-Demons

Boris Jabes is a legend because he took this to heart and put it on his wall. Does Microsoft need a copy for every employee?

Herb, I know there is great work here, despite how it sounds, but since you are on the C++ standards team, why not get your ideas standardized first? I know you will say "because it doesn't work that way", fine, but we will feel better for it.

So since I didn't see a standards proposals entitled:
C++ Reference Counting - Herb Sutter.
Problem: shared_ptr, auto_ptr - ugly and hard to optimize. Proposal: ref class/ref new.

or

C++ ABI problems - Herb Sutter.
Problem: lack of abi:, Proposal: [[abi attributes]].

How about it, right now? Microsoft's blog community might even help you, instead of feeling like they are against you, and before WinRT and C++/CX becomes the next Windows Phone failure, despite how good it is.

If ^ and gcnew is just com pointers in the compiler ... couldn't we hide that uglyness in a library. Behind a smart pointer interface, and behind overloaded new? To create metadata or WinRT types I think a pre or post build step would have been much better. Something that takes standard iso code and adds metadata to it, and adds com wrapper types, and whatever it needs. Surely there should be a way to hide the CX code behind a ISO C++ layer. Even if this layers has to do a lot of conversions to and from CX::vectors and CX:Strings to std::vectors and std::strings. I think most of us would choose cleanliness, over features or even speed. I think a lot of the anger in this comment section has a lot to do with PR. While marketing people like surprises, programmers don't. Programmers like to think they have a say in their future. If this work had been done openly, and not in secret. That way feedback like this could have been given sooner. Now its too late to change anything.

@Glen:
First, lack of C++11 language progress since VC10 is hard to forgive when your own polls show customers want C++11 by a margin of over 4 to 1 over anything else. Proof:
http://visualstudio.uservoice.com/forums/121579-visual-studio/category/30937-c-


"their own customers": this is obviously a uservoice forum only advertised amongst C++ developers so far.
Currently, Visual Studio gets a way higher revenue coming in from managed developers than native ones.
Compare the size of this with http://dotnet.uservoice.com/forums/4325-silverlight-feature-suggestions
and that's only a tiny fraction of managed developers.

Count me among the disappointed in the "renaissance". I sure won't use C++/CX. WRL, maybe, maybe not, but not another language extension.

If, as Ralph says, the number of C++ developers interested in Visual Studio is significantly less than the number of analogous .NET developers, and this is grounds for not doing much wrt C++11, all the more reason to stop using Visual C++ and start using ICC or, say, GCC.

@ralph: Hi ralph! I find nothing to disagree with in your post though I'm unclear where you are relating your point to mine. :)

To clarify what I meant:

I used the term "their own customers" because the poll I linked to (which was also linked by someone earlier) is a Microsoft supported poll and introduced by Microsoft in the header:

"We look forward to hearing from you!
Thanks – Doug Turnure
Visual Studio Team".

Regardless, it's essential to remind MS that when native developers vote for more C++11 over more proprietary WinRT support by a majority of 4-1, then they expect to get that first, whatever any other group might want. If there's a conflict, then hiring more people for the C++ feature crew is the right answer - especially when money is not an object for them and when many feel that the C++ feature crew is a "one man and his dog" show as it is.

It's also important to remind MS that it mocks its customers when it encourages them to vote, but then ignores (as MS often does) their most popular choices (like resizeable dialog boxes or bug fixes). It then invites more anger when Microsoft delivers much harder to implement but much less voted for items (like WinRT and C++/CX), before easier to implement ones that receive way more votes (like more C++11).

It goes double when what a community has resoundingly asked for is neither unusual nor unexpected, but essential to their core eco-system. The vote was for no less than the international standard on C++ - the holy grail if you like for C++ users. Nothing else will ever be of more importance to C++ users as it is what underpins developer and platform freedom (including C#'s!). Microsoft could even *guess* this outcome without a poll at all! When Microsofts main competitors did exactly that infact, what's the hold up here? Bad management or politics?

With so much mistrust from C++ developers to account for, "mistake" can't be assumed nor accepted indefinitely; and mistakes like these and the issues of presentation are simply insane for Microsfot to keep making when their platforms need C++ developers and native too. Windows Phone has so far tanked without this, for example. So C++ counts! (But should it ref count now too is another question!?)

Even *if* managed developers are a bigger slice of Microsofts customer base (if that was your point), native code is as important as it effects the viability of the whole platform (which is why WinRT was developed). If your point was that managed developers should continue to get priority, since their community didn't vote for a new native stack one can argue their priorities were ignored too! So we agree!

It's good that Microsoft has realised that right now managed code just doesn't cut it when used right through the software stack. That they invented WinRT to retain the native layer under things and get the performance up on Windows and other products and on less powerful ARM devices shows that.

It's also ironic that CPU diversity caused this when one could have naively assumed (as Microsoft probably did) that diversity would encourage only managed code rather than native too! But the same principle can occur on the server where Managed C# and ASP.NET have a popular community. Here too C++/native can fly high and may well do as customers can control the hardware and want the huge cost savings that native can yield.

So all in all, this shows that MS were wrong to go down the managed path so firmly (not wrong completely).

My issue though is that they were more wrong to try to force that mistake onto other C++ developers; which they did when they virtually abandoned C++ tooling for C#'s over the last decade. The mistrust that decision caused runs so deep that many VC++ developers will never put themselves in that situation again. If the platform needs to be left to do that, so be it.

It's not about C# vs C++, or managed vs native. I know and use both and have a ton of respect for the place of both - as well as Herb. Sure I prefer C++ in the right situation, but I prefer freedom over either. So this is about code portability (developer freedom) and business transparency to allow that.

If Microsoft's style had not been one of stone walling customers, picking winners, getting it wrong, ignoring customer priorities, re-inventing new stuff over fixing old stuff all the time, flip/flops, fragmenting user bases and now potentially creating walled gardens - and dubious presentation of all of this - then I wouldn't be writing this.

But it is, and that's what we should be concerned with.

Where C++/CX fits in here is it that it has the ability to empower C# and C++ *or* just divide C++, so we need to marshal its arrival carefully and be onto Microsoft in the same way. If we can't achieve that, Microsoft and C++/CX should be dropped and we should let Microsoft know that.

C++/CX has the power to make MS a better friend or a bigger enemy. It all depends on what they, and we, do with it. I will ask and comment about that in my next posts. The jury is out.

However, it is essential developers and bloggers hold MS and others accountable to better ideals more than worry over C++ vs C# or native vs managed. MS should support all of that diversity in whatever way(s) each respective community expects, not corral or hold back any language or community or take excessive advantage. Lets ensure thats what happens!?

@Dale: I'd say keep an open but cynical mind about C++/CX. Despite what it sounds like, IMHO C++/CX and WinRT are potential master strokes, if I understand them correctly. I just didn't want them to a) arrive before more C++11 features; and b) as with WinRT to arrive in silence instead of via a roadmap; and c) for C++/CX to arrive without first some debate or a proposal to the C++ standards body - especially when it's architect is a core member of that group.

While I trust that Herb knows what he's doing and that standards folk prefer to standardize existing practice; that isn't always the case. One can argue that getting C++/CX out there creates existing practice, but anyone can argue that for anything and even if C++/CX was to be standardized later, you never know if it can or will be done in a compatible way with what exists before the standard.

I'm very keen to see @Bjarnes opinion on C++/CX? Does anyone know? Herb I'm sure you know!? and in particular to know if anyone credible feels it even should be submitted to the next C++ standards as a proposal? If so, I'd like to see Herb do exactly that *now* and not make it some other "standard" as C++/CLI remains.

Until then, I have to say - and this may be surprising or controversial, or just plain wrong - that until credible alternative views on C++/CX (or MS's positioning of it) surfaces (in which case my whole view could change): for now I think C++/CX should be embraced as a way better way to go than using smart pointer classes - but only where it relates to MS *and* COM. Elsewhere I'd stick to standard smart pointers.

I can just imagine how much cruft MS COM code Herb has just signalled the execution of at MS and other places in Windows, Office and other products! In that context and until other views change the consensus, we should thank Herb a lot for that! Thanks Herb! I don't think we should assume too much though re: the "C++" renaissance. That still remains to be proved.

@everyone: We need more sensible debate on this blog and elsewhere about these questions and opinions I am expressing. Help!

I am also keen to see if WinRT and C++/CX will be used to disconnect VS 11 or 12 from the CLR etc. and if it will be much faster for it, as I and many others suspect? If so it will eventually give users the #1 thing they voted for - an IDE speed up! It will be interesting to see who was right about that, if it happens at all?

However, the bottom line is I just wish to see C++/CX as part of ISO C++ until someone like Bjarne tells me that's a bad idea and I remain concerned that everything VS generates (which is a lot) and much that we write by hand will only compile with an MS compiler and/or be non standard code or used to create a walled garden of ^'s. This is one part I think Herbs "just at the edges" comment underplays the significance of IMHO.

All of this needs to be understood more clearly and everyone should keep pushing MS to give both a clear timeline for C++11 features (and refuse to accept not having that as it IS possible) and I'd like to see Herb start offering his opinions and more importantly plans on the same regarding C++/CX as it relates to ISO C++ Next (I am assuming after 11).

So Herb et al, what's that story? More detail please! :)

C++/CX is absolutely NOT what I want to use. I want to use C++11. I don't buy this "you only have to use C++/CX on the border" business. The border is important! I can't believe Microsoft is once again pushing their own incompatible with everything solutions instead of implementing the standard.

Glen:

> I am also keen to see if WinRT and C++/CX will be
> used to disconnect VS 11 or 12 from the CLR etc. and
> if it will be much faster for it, as I and many others
> suspect? If so it will eventually give users the #1
> thing they voted for - an IDE speed up!

Quite honestly, it seems much more likely that Microsoft will ignore the performance problems with Visual Studio for a year or two, no doubt saying that they hear us and that we should be patient. Then they will drop C++/CX in favor of some new C++/CY and we will be back to where we are now.

Will WinRT and WRL be available on Windows Phone? I. e. will we be able to develop for Windows Phone in C++?

Apple has Objective-C - compatible with nothing, no portable 'cos is strictly related to their OS and no one complain. When You write stuff related to MacOS, you have to use C-Obj. Of course, you can use gcc to compile C-Obj on other platform, but it has not any advantages. I think, MS just did the same, they provided exotic C++/CX to glue system WinRT with apps's bussines logic written in ISO C++.

@miriam: I definitely agree with your sentiment.

Your view is simple and IMHO yours will be the most common one (and exactly mine) unless MS takes the steps I advocated in my previous post.

Without other compiler support - or better, ISO support - C++/CX will just be seen as denting the C++ "brand" or locking C++ into an MS walled garden.

If Microsoft does that, they will continue to hurt their own brand and be seen as developer unfriendly and the "C++" renaissance will be seen to be nothing more than a "Microsoft only" "native renaissance" for self serving reasons that has little to do with C++, just native.

In which case, C++ developers will and should continue to leave the platform as a whole because Microsoft will be taking too much advantage of customers to protect their platform.

Not to contradict, but Miriam, if you do actually need to integrate with MS and COM (so can't avoid it), are you sure C++/CX isn't a more elegant solution for improving the writing and using of very ugly COM than without using it? To me, C++/CX really appears to improve the situation quite a lot if used simply an an MS specific solution to an arguably already MS specific problem. If used for only that, I think C++/CX is a better mousetrap. If you are stuck with a lot of MS specific code anyway, you'll have *a lot* less of it after using C++/CX? In this context, don't you think C++/CX has technical merit?

Of course "an MS solultion to an MS problem" is really just swapping one problem, for an arguably smaller one now, that will be a bigger one later.

So maybe your simplistic view still holds well! There is a lot to be said for simple! :) The "borders" do matter as you say.

But whilst MS insists on using COM as the border. I think C++/CX is the better solution than not using it if you are going to support MS at all.

Your mood shows though that MS should not take anyone for granted though. A lot of developers are posting that they are leaving the MS platform and your views succinctly sum the simple, but possibly eventual, picture up.

@pau: good question! @ms - awaiting lots of answers!

@asd: You may be right re Obj-C etc., one might view it as the equivalent. How do you view clang in that context?

Glen:

> if you do actually need to integrate with MS and COM
> (so can't avoid it), are you sure C++/CX isn't a more
> elegant solution for improving the writing and using
> of very ugly COM than without using it?

I thought about this for some time, and surprisingly (to me), the answer is no, C++/CX not that much more elegant than just plain COM with _com_ptr_t. We use COM in a lot of places in our code and, well, I can't see how C++/CX would make the relevant code sections much cleaner. Passing around a smart pointer is exactly the same as passing around a hat pointer, calling interface function is the same save for exceptions (and this is actually a minus for our code, we don't want exceptions in COM code), etc. There are new features like events and generics, but we aren't using them now and I don't think we'd like to start using them in the near future. Templates in the internals of the module - great, generics on the border - meh, maybe that's good for Microsoft since they are writing libraries, but we aren't like them, we write applications.

It seems that in the short term, switching from smart pointers to C++/CX will buy us exactly nothing. And the long term future, you know, seems highly questionable.

I'd gladly trade this C++/CX as well as a dozen next C++/CY successors for one real thing: C++11.

@Miriam: Thanks for replying. Myself and many will agree with you regarding C++11. Keep asking for timelines for that! We can't get away with not giving them, how come Microsoft can!? :)

Regarding C++/CX:

@Charles and @Herb: There you go!

You now have two reasonable but conflicting views regarding the value of C++/CX. I think both views are quite reasonable but prooves that if reflected widely, 50% of the community might be wrong about C++/CX!

That would be damaging IMHO.

Anyone care to help us get nearer to consensus by post in some comments/examples that might help us get to one.

Miriam is saying she can't see how C++/CX does that much to clean her code up. @Herb (or Charles or anyone!), this is your movie, can you promote a little more over here and sell us. Thanks!

I see this as opening up a new market for C++ developers.  There will be demand and developers will step up to meet that demand. 

Companies for profit are not in the business to advance a standard open language or technology.  They are in the business to make money.  C++ happens to fill well into this particular model. 

Look to the open source community for the advancement of open standards.

@KMNY_a_ha: Interesting point.  I still think it creates a good market for developers, provided the whole Metro thing is successful, which I think it will be.  But I can also see the point of view where it's better for developers to have open standards, cross-platform, re-use, more choices, etc.  Of course it's not unique to MS to want to lock developers into a particular platform.

@BarryDale:

Hi! Your posts are pragmatic and likely correct.

My views were initially exactly like that of mmojonez right at the beginning of this blog.

However, we shouldn't be too accepting. It's as dangerous as being too fearful. These platform developments have yet to play out, but there appears to be as much to be concerned with, as to be pleased about.

At times like these, all we can do is be hopeful; voice our concerns; and let people pick through the worthy concerns versus the not so worthy and try to work out what the consensus is. Doing that will be easier if we remember that some people will be more affected by these developments than others and that most of us are still trying to just undertstand it. Discussing things in a helpful, forgiving way, will be key to doing this and may well effect the outcome.

@KMNY yes that means having a healthy *BS* detector too.

In that spirit, here's my concerns:

I agree companies need to make a profit but how that happens is important. We are companies too, not just Microsoft or Apple. Tight controls on the distribution and innovation channels hurt the ecosystem of the many for the sake of the few. Do you love your phone companies or like paying for unreasonable bandwidth caps? I don't. I don't want my tech companies (whether I benefit or not) to go the same way and adopt the same attitudes and lack of principles.

We have to vote with our feet or accept the outcome, but being organised and innovative helps fight dictators. Organisation IS the internet and innovation IS what we do and understand so lets not just hand our head on a platter on whatever terms these big monopolies care to offer. If you can use open source to avoid that, you might have to.

We have had a pretty free (of some definition) ecosystem until recent years and that is now changing. For good and for bad.

Apple, Microsoft and Google are making big plays. What I see though is an attempt to corral applications like cattle and then milk them. That's good for farmers but not for cows. Which one are you and which one do you want to be?

In the past companies locked you in through innovation - Win32 - and other companies freed you through innovation - QT. Now we have walls going up. Companies are blatantly blocking innovation where it threatens them.

Look at Flash, poor Adobe. Look at plug ins - was banning them aimed at locking out that heap of innovation that is Google Native Client?

Sure Jobs can say Flash is crap and a battery drain. Sure Microsoft can say plugins, ActiveX, and all that are mostly used for deceit and viruses. Claims like these are totally true. But is that why they were banned? It seems to me that anything that can create a platform within a platform is now being targeted. That's not innovation, that's protectionism! It's also profit as you say, but for who and how legal? The whole of Windows is a virus playground but look how long it is taking to fix that! They didn't ban themselves in the meantime.

I asked the Javascript/Metro browser guy about using C++/CX in the browser. Can I extend the browser with my own UI controls? Or write games in the browser? No: C++/CX is blocked from drawing he tells me. So basically that platform and channel is locked down too. If you want C++/CX in the browser, it appears all you can do is composte basic HTML elements with it. This "advance" doesn't seem to offer as much as it could. Why? Is it to stop you creating a platform within a platform again? But you can lock yourself into C++/CX, just not for as much gain as it could have been.

If that's the case, should one just use ISO C++ on the server and Linux and avoid the lock in? I can composte without lock in for free there. So why not do it?

Where is this leading? Previously MS built the platform and customers paid for it; developers had a free channel to the platform which made it viable and valuable so it could grow more. Win win. Now MS and Apple and no doubt Google are looking to make the money from the developers instead. These are the people that make the platform valuable in the fist place.

So has the deal now become: I pay MS so that I cam make their platform popular and grow their business while they lock me in and confine mine?! Hmmmm

I may be wrong about some of this, so forgive me, the facts aren't yet clear. The goal here isn't to stir up anti-MS feeling. I'm all for MS as much as any of them. Infact, MS is mostly what I know, but maybe I need to change that if any of this starts turning out the way that it looks. Maybe other people are thinking the same?

There's a lot to pick through. I'm just kicking the tyres; seeing what comes out; and trying to be balanced whilst raising what I see to be the concerns (and benefits). If we can get people talking a shared wisdom can be built.

I am sure you are doing the same, but be sure you don't get taken for granted.

I'm keen to hear other points of view on all this.

@Glen: Those are some well thought out and interesting ideas you put forth.  Yes, open dialog is great.  I'm interested to hear other thoughts as well.

So Microsoft. with all the geniuses that you selectively and carefully hire you are still unable to create a clean C++ interface ? what a shame.

Window calculator; 

calculator.add_button( Button("1") ); 

for_each( begin( calculator.buttons ), end( calculator.buttons ), HAVE_FUN );

all MODERN C++ features in use. no alloc / IUnkown carbage.. please..