.Net isn't going anywhere. The "C++ renaissance" thing is just a ploy to cater to people who think C++ is the only language you can use for "real programs."

this is so scary..I dont want get old and programming in c++ just because I like it and having no real motive to.. T_T me like c++ so much

I hope this is the case, but I'm not as confident as you are. MS are no longer pushing .net the way they were. Look at the failure of WPF, and the subsequent return to C++ in winRT.

Why was WPF a failure? It probably won't be used much anymore, but programming for windows 8 is pretty similar to WPF, and would probably still be considerred WPF if they hadn't made winRT so compatible with .Net.

[quote name='ChaosEngine' timestamp='1354572600' post='5006800']
I hope this is the case, but I'm not as confident as you are. MS are no longer pushing .net the way they were. Look at the failure of WPF, and the subsequent return to C++ in winRT.

Why was WPF a failure? It probably won't be used much anymore, [/quote]

How was it anything but a failure? It had some nice features, but almost no-one ever used it, it was complex, memory hogging and failed to get simple things (focus, tab order) right. I spent 3 years working with it, and it used 10 times the memory of the equivalent winforms app.

programming for windows 8 is pretty similar to WPF, and would probably still be considerred WPF if they hadn't made winRT so compatible with .Net.

There are some similar concepts, but I think replacing the entire runtime and api of a library can be considered to be a "new axe". But the most important difference is that WPF was a managed library from the ground up. From a win32 perpective it was one owner drawn window that managed everything internally. WinRT is not managed.


Good overview of the history here.

How was it anything but a failure? It had some nice features, but almost no-one ever used it, it was complex, memory hogging and failed to get simple things (focus, tab order) right. I spent 3 years working with it, and it used 10 times the memory of the equivalent winforms app.

No offence but this (as you probably already know) is a lot like the many many (far too many) whiny comparison threads between WPF and WinForms over the years (no different from the annoying C# vs C++ ones either), which almost always gets resulted in links to http://msdn.microsoft.com/en-us/library/aa970683.aspx or something VS2010 related. The extra features it has are not only overused but are likely the reason why so many people complaint about performance; element collisions, multiple effects on elements, effects created on the CPU, animations, animated layout, using media element, 3D content on the CPU are just some of the 'features' that are badly abused, it was almost like people thought WPF was used to make over pretty UI controls that were no different from game entities then apply collision and other pointless crap to them.

WPF gets considered complex, on other forums this may make sense but on a gaming forum WPFs learning curve is a small fraction of what people would have to learn to make even the simplest game, not that it makes any difference since Windows 8 uses XAML so any complexities would be unavoidable if they moved onto Windows 8 anyway.

As for your 'getting simple things right' comment, I am eager to hear what you were trying to do and how you achieved it. Now I have only been using WPF / SL / WinForms for 2 years (although that doesnt mean much since total years != total hours) and while I use all three for different things, my decision is NEVER based on memory consumption mainly because any visible lag is my own coding error and it would seem all the memory complaints after .Net 4 were to do with visual effects. If anything the only resource drainage is from XAML editor in Visual Studios, something that is non-existent in Blend

Besides if you read up on current performance issues, it is almost always to do with effects, media, animations, ink canvas effects or some other eye-candy thing that typically you wouldnt really want to do on the CPU anyway, all which can and should be done using surface sharing via SharpDX / SlimDX. I think the issue with WPF is MS advertised it as a framework for making over the top pretty apps with animations and 3D effects both of which I would never recommend doing directly from WPF.

How was it anything but a failure? It had some nice features, but almost no-one ever used it, it was complex, memory hogging and failed to get simple things (focus, tab order) right. I spent 3 years working with it, and it used 10 times the memory of the equivalent winforms app.

We're slowly switching all of our in house tools to WPF because it is more performant than winforms.

I don't really want to derail this thread more than it already has been. Suffice to say I worked on a LOB app with WPF for over 3 years, so I'm not just making this stuff up.
If you're still keen to discuss WPF, PM me or start another thread.

I'm more interested in ApochPiQs assertion that C++ is being pushed as some sort of sop to C++ programmers. I'm really not sure of that. MS are even pushing another C++ extension (C++/CX) as the best way to develop for win8.

I suppose my concern is part of a wider uncertainty in the industry, and specifically Microsofts position in it. No-one really knows how people are going to compute in the future. Looking at the industry now, it seems pretty clear that the trend is all away from the desktop and splitting between "apps" and the web. But at some point, this is going to start affecting the enterprise sector (it probably already has with the release of Win8). It will be very interesting to see what the demand is in the next few years. Are people going to demand a rework of productivity apps to move to web/touch or will we see people decide that old school kb/mouse desktop apps are what lets them get work done?

Games and engines will be indirectly affected by this due to language support and tooling.

Laptops are here to stay. The sales of them may go up or down, but the devices are so much more capable than any other mobile device that I am convinced about their long term slow steady growth. I believe that more people will realize the keyboard, bigger screen, gaming, and other advantages of the laptop computer over other mobiles once the realization arrives in people.

Apple and all the others will release more mobiles and consumers will play more games on them - long term, is my prediction. Microsoft has planned for this probability, don't you think? This is part of the reason why C++ is being pushed. Most of the establishment uses C++ and it fills a gap while other technologies continue progressing. The competitors will not wait for a Microsoft response and cross-platform gains are an immediate threat to market share. It is ironic that Bill Gates is rumored to have once said something along the line of games have no business being played in a PC, yet the PC is a proven area where games can be marketed and sold as an advantage for Microsoft. After Bill Gates stepped down, we saw the C#/XNA cycle and now we see a C++ one - both motivated in response to competitors, I believe. Another thing to remember is that there are in general many C# programmers in the world which will always spill into the game development genre.


Clinton

I don't really want to derail this thread more than it already has been. Suffice to say I worked on a LOB app with WPF for over 3 years, so I'm not just making this stuff up.
If you're still keen to discuss WPF, PM me or start another thread.

I've pretty much only worked on WPF (LoB apps too) for years and found it crazy fast, but we didn't go for any "fancy new looks", just for the nice programming models it allows through MVVM. Switching to that from web (i wasn't doing web before, but i suggested we switched internal LoB apps from webforms to that) boosted productivity close to 10X (yes really) and the only performance issue i ever had with WPF was the about 1 second application startup time, everything else was a breeze both from a programming speed standpoint and from a runtime speed one. I'd be curious to know where you've ever hit speed issues.
Also what's important in WinRT's similarity to WPF is that it's the same as not droping WPF, porting from WPF to WinRT is beyond trivial, so there's none of that usual huge cost to switch. It also goes a lot in favor of .net, saying "well .net is the clear winner, look now you can access it from JS & C++ too because we feel it was so good" to me that sounds like pushing .net, under another name, not like going back on it. Microsoft definately seems to be strongly pushing the .net & WPF ideas forward, renaming them is a detail, and making them available through more languages is a very good bet!

Game engines are not created everyday. This is a long time investment, and thus requires really good fine tuning. C++ isn't going anywhere from this niche.

Creating a Game is a different matter, and C# can be efficiently used in that domain...