With Win8 now out, it's clear that WinRT is a managed runtime, a slightly tweaked .Net CLR. Future C++ development for Windows will now require proprietary managed C++, so talk of "standard-compliant" C++ in future versions of Windows is mostly moot, at least as far as consumer markets go. Win8 will be the start of transition towards Windows being a full .Net stack, taking hardware vendors out of the equation.

The old run-time will continue to serve legacy applications but will likely be delegated into running as virtualized. Since it doesn't appear that Win32 will be getting any of the new facilities, Win32 doesn't look like viable commercial option for the future.

I'd estimate that despite being listed as C++, native code in Metro will be phased out during 8 and 9 since C++/CLI Metro apps can just compile to bytecode instead. To those that might remember the "undocumented API" wars of the 90s, this is Microsoft's perfect execution of that. And unlike 10 years ago, they no longer have a monopoly, so they're free to do as they please with courts not being able to touch them.

While it may not seem like a big deal, this change makes all existing tools and just about all third-party libraries obsolete as far as Win8+ goes. And with release cycles, my guess seems to have been quite accurate. Moore's law and current characteristics of mobile devices imply that during the next 2 versions managed runtime will become sufficient for effectively all but most demanding applications, effectively giving Microsoft better platform exclusivity than what Apple has today.

Outside of legacy support, this leaves Google as the last C++ supporter. But unlike Apple or Microsoft, they don't have their own desktop platform, an IDE, a business API (role of .Net) nor a compiler. Overall, a fairly poor position to be in. And with mobile market finally being completely partitioned and interoperability no longer relevant, it might force Google to push for their own exclusivity by introducing their own technology stack, they just lack anything even resembling a mature alternative.

I'm sorry, how is GLSL a high level language (I don't know about the direct X shader language, but I can't imagine it's very different)? It's not managed, they have to be compiled and linked, and they're strictly procedural. GLSL reads like a subset of c++.

Umm, maybe the definition has changed over the years, but when I was in school, almost anything that wasn't assembly was a high level language. C/C++/C#/Cg are all high level languages.

I'm sorry, how is GLSL a high level language (I don't know about the direct X shader language, but I can't imagine it's very different)? It's not managed, they have to be compiled and linked, and they're strictly procedural. GLSL reads like a subset of c++.

Umm, maybe the definition has changed over the years, but when I was in school, almost anything that wasn't assembly was a high level language. C/C++/C#/Cg are all high level languages.

As someone who is probably the around same age as you ( when C was consider a high level language ), the definitions have very much changed, and frankly regardless to it's stupid name, GLSL is not a high level language by today's standards.

Now, the worst part is, it comes down to a matter of semantics, as "high level" is short hand for "a high level of abstraction". You can easily argue if something is "highly" abstracted or not till the cows come home, but to get away with vagaries like "high level" you need to compare yourself to your contemporaries, in which regard, GLSL is anything but high level.

I see no reason that an evolving language would disappear from game development in our lifetime.
As long as the language is evolving then whatever wonderful things become popular in one language will eventually make their way into C++. It is only the things that fundamentally cannot be done from the paradigms possible in C++ which would ultimately become a major obstacle.
It's just really a question of whether the right features make it in quick enough, whilst also taking the time to thoroughly evaluate and eventually leave out those that would later widely be criticised as a mistake (like throw specifications).
A few thoughts:

Did Pascal die out? That's debateable. Sure it evolved somewhat into various incarnations which got their own name such as Delphi and now the latest one being oxygene. But really, it's still pretty much Pascal right. "If you call a rose by any other name...".

What about Basic, did that die out? I wouldn't say so. The main contender currently being VB.NET. Again, it's still pretty much Basic.

And if you are of the position that when a language changes then it's dead and a new language is born, then how many times has C++ been reincarnated so far...?

The C++ of 30 years from now might have considerable differences from what it does today, but it'll still be there and used in game development, even if I'm the only one left using it dammit!

I honestly don't see a point in this thread. These threads never result in much productive anything.

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.ScapeCode - Blog | SlimDX