Which platform?
-
So, we are just about to begin a new project. We're now deciding which platform should be used. The bosses asked me about this, and I replied that my bet was on C++ and Win32, as usual. A colleague voted for Java ( X| ) and someone there even dared to suggest VB ( X| X| ). At any rate, the bosses are worried about the future of C++ and Win32. They read somewhere that Microsoft's next OS won't be supporting anything but .NET Framework, so they are not convinced that C++ with Win32 should be the best option. So I'd like to ask for your opinion about this... C++ still has a future? Should we choose C# and .NET over good old C++ and Win32? Thanks.
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
Depending on the type of application, you might even consider Ruby. We have written several Ruby GUI apps (using FxRuby) that are well received. 1) For performance and heavy lifting (apps like Internet Explorer, Database servers, networking, high end graphics) - C++. 2) For quick, troublefree, functional desktop apps / batch processing - Ruby. 3) For web - C# / ASP
-
Chris Losinger wrote:
it'd take even longer if nobody wants to buy it if using it means buying new versions of all their apps (see Adobe + Vista - something that might've made me delay Vista for another year or so, if i'd known about it before i bought my latest PC with Vista pre-installed).
Yeah, but here it's more a case of Adobe refusing to update their code so that people'd buy their new version. It's not really a case of a native-code incompatibility - I mean their new version that will run on Vista is still a native app (talking of Photoshop here).
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. (*Sample chapter available online*)Nishant Sivakumar wrote:
Yeah, but here it's more a case of Adobe refusing to update their code so that people'd buy their new version. It's not really a case of a native-code incompatibility
Adobe's motives are not the relevant issue here. if i was still thinking about getting a new PC, my options are: 1) get a new PC with Vista and spend $1200+ to get versions of Photoshop and Illustrator that work on the new machine... whenever those versions come out. 2) get a new PC with XP and use my existing Adobe stuff if MS abandons native code, everybody with a PC is going to face that same issue, except it's going to be for more than just Adobe's stuff. big-name publishers aren't going to release free upgrades to their .Net versions, the cost of PC just went up by the amount it costs to replace all that software. awesome!
image processing toolkits | batch image processing | blogging
-
Nishant Sivakumar wrote:
Yeah, but here it's more a case of Adobe refusing to update their code so that people'd buy their new version. It's not really a case of a native-code incompatibility
Adobe's motives are not the relevant issue here. if i was still thinking about getting a new PC, my options are: 1) get a new PC with Vista and spend $1200+ to get versions of Photoshop and Illustrator that work on the new machine... whenever those versions come out. 2) get a new PC with XP and use my existing Adobe stuff if MS abandons native code, everybody with a PC is going to face that same issue, except it's going to be for more than just Adobe's stuff. big-name publishers aren't going to release free upgrades to their .Net versions, the cost of PC just went up by the amount it costs to replace all that software. awesome!
image processing toolkits | batch image processing | blogging
Chris Losinger wrote:
if MS abandons native code, everybody with a PC is going to face that same issue, except it's going to be for more than just Adobe's stuff. big-name publishers aren't going to release free upgrades to their .Net versions.
I get your point. But it's still speculation that MS will abandon native code for user mode apps. Some of the new/updated API may be backwards-incompatible and we may be forced to update our apps in minor to not-so-minor ways, but I personally am sure that we would not be forced to move to 100% managed code. But there may be a future OS (10-15 years from now) when we may be forced to do that. Don't you think it would be foolish to ignore such a possibility and to insist on writing only native code?
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. (*Sample chapter available online*) -
So, we are just about to begin a new project. We're now deciding which platform should be used. The bosses asked me about this, and I replied that my bet was on C++ and Win32, as usual. A colleague voted for Java ( X| ) and someone there even dared to suggest VB ( X| X| ). At any rate, the bosses are worried about the future of C++ and Win32. They read somewhere that Microsoft's next OS won't be supporting anything but .NET Framework, so they are not convinced that C++ with Win32 should be the best option. So I'd like to ask for your opinion about this... C++ still has a future? Should we choose C# and .NET over good old C++ and Win32? Thanks.
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
My rule of thumb is: if many people are going to use the software, and/or I plan to support it for a long period of time, C++ is the way to go. For ad hoc write-and-forget stuff, internal applications, etc, C#/VB/Java/Perl/whatever is often a better choice.
-
Chris Losinger wrote:
if MS abandons native code, everybody with a PC is going to face that same issue, except it's going to be for more than just Adobe's stuff. big-name publishers aren't going to release free upgrades to their .Net versions.
I get your point. But it's still speculation that MS will abandon native code for user mode apps. Some of the new/updated API may be backwards-incompatible and we may be forced to update our apps in minor to not-so-minor ways, but I personally am sure that we would not be forced to move to 100% managed code. But there may be a future OS (10-15 years from now) when we may be forced to do that. Don't you think it would be foolish to ignore such a possibility and to insist on writing only native code?
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. (*Sample chapter available online*)Did you happen to catch the Channel 9 video that interviewed the guys on the C++ team? They indicated that Orcas would have increased emphasis on native code development. This does not sound as if they are getting ready to retire native code support any time soon.
-------------------------------- "All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke
-
Did you happen to catch the Channel 9 video that interviewed the guys on the C++ team? They indicated that Orcas would have increased emphasis on native code development. This does not sound as if they are getting ready to retire native code support any time soon.
-------------------------------- "All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke
Richie308 wrote:
Did you happen to catch the Channel 9 video that interviewed the guys on the C++ team? They indicated that Orcas would have increased emphasis on native code development. This does not sound as if they are getting ready to retire native code support any time soon.
Yes, I didn't see the video but I did talk to some of them last week (at the MVP summit). VC++ Orcas is definitely about enhanced native code support, specially in MFC.
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. (*Sample chapter available online*) -
So, we are just about to begin a new project. We're now deciding which platform should be used. The bosses asked me about this, and I replied that my bet was on C++ and Win32, as usual. A colleague voted for Java ( X| ) and someone there even dared to suggest VB ( X| X| ). At any rate, the bosses are worried about the future of C++ and Win32. They read somewhere that Microsoft's next OS won't be supporting anything but .NET Framework, so they are not convinced that C++ with Win32 should be the best option. So I'd like to ask for your opinion about this... C++ still has a future? Should we choose C# and .NET over good old C++ and Win32? Thanks.
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
Last time I checked MS only controlled windows operating systems. I imagine a solid future for c++ until they make a better, faster language.
File Not Found
-
So, we are just about to begin a new project. We're now deciding which platform should be used. The bosses asked me about this, and I replied that my bet was on C++ and Win32, as usual. A colleague voted for Java ( X| ) and someone there even dared to suggest VB ( X| X| ). At any rate, the bosses are worried about the future of C++ and Win32. They read somewhere that Microsoft's next OS won't be supporting anything but .NET Framework, so they are not convinced that C++ with Win32 should be the best option. So I'd like to ask for your opinion about this... C++ still has a future? Should we choose C# and .NET over good old C++ and Win32? Thanks.
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
-
Nishant Sivakumar wrote:
Yeah, but here it's more a case of Adobe refusing to update their code so that people'd buy their new version. It's not really a case of a native-code incompatibility
Adobe's motives are not the relevant issue here. if i was still thinking about getting a new PC, my options are: 1) get a new PC with Vista and spend $1200+ to get versions of Photoshop and Illustrator that work on the new machine... whenever those versions come out. 2) get a new PC with XP and use my existing Adobe stuff if MS abandons native code, everybody with a PC is going to face that same issue, except it's going to be for more than just Adobe's stuff. big-name publishers aren't going to release free upgrades to their .Net versions, the cost of PC just went up by the amount it costs to replace all that software. awesome!
image processing toolkits | batch image processing | blogging
-
My rule of thumb is: if many people are going to use the software, and/or I plan to support it for a long period of time, C++ is the way to go. For ad hoc write-and-forget stuff, internal applications, etc, C#/VB/Java/Perl/whatever is often a better choice.
Hey - I got a reply notification from you, but the post's gone now. Accidentally posted some NDA stuff?
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. (*Sample chapter available online*) -
Depending on the type of application, you might even consider Ruby. We have written several Ruby GUI apps (using FxRuby) that are well received. 1) For performance and heavy lifting (apps like Internet Explorer, Database servers, networking, high end graphics) - C++. 2) For quick, troublefree, functional desktop apps / batch processing - Ruby. 3) For web - C# / ASP
Vivek Rajan wrote:
For quick, troublefree, functional desktop apps / batch processing - Ruby.
Hows That? Using what UI toolkit? And, how about deplploying that thing? Have you ever tried to build a ui with Ruby? It's a complete pain in the tail using tk or wX. If it weren't for rails, we wouldn't be talking about ruby at all. And, IMHO, batch processing should happen quickly, ruby's current VM is slower than molasses.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
-
Hey - I got a reply notification from you, but the post's gone now. Accidentally posted some NDA stuff?
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. (*Sample chapter available online*)Nishant Sivakumar wrote:
Accidentally posted some NDA stuff?
Not really, but it occured to me that maybe the person I heard the news from may not be happy about my post :)
-
Nishant Sivakumar wrote:
Accidentally posted some NDA stuff?
Not really, but it occured to me that maybe the person I heard the news from may not be happy about my post :)
Nemanja Trifunovic wrote:
Not really, but it occured to me that maybe the person I heard the news from may not be happy about my post
Okay, the mail notification has been erased - so it's all good now.
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. (*Sample chapter available online*) -
So, we are just about to begin a new project. We're now deciding which platform should be used. The bosses asked me about this, and I replied that my bet was on C++ and Win32, as usual. A colleague voted for Java ( X| ) and someone there even dared to suggest VB ( X| X| ). At any rate, the bosses are worried about the future of C++ and Win32. They read somewhere that Microsoft's next OS won't be supporting anything but .NET Framework, so they are not convinced that C++ with Win32 should be the best option. So I'd like to ask for your opinion about this... C++ still has a future? Should we choose C# and .NET over good old C++ and Win32? Thanks.
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
If performance and portability matters, C and or C++ hands down. There is a healthy number of 3rd party ui toolkits and frameworks that give MFC etc a real run for their money. If it's a business app doing the database thing and you aren't worried about future ports to other operating systems, then C# & .net would be the top contender in my opinion. And, C++ isn't going anywhere anytime soon. Disabling user-mode native code would be absolutely insane and incredibly stupid and I seriously doubt that MS is that foolish.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
-
Yep, I know... I'm going to rephrase the question. Should we even consider C++ and Win32, given the fact that Microsoft could not support it in the next version of Windows?
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
Fernando A. Gomez F. wrote:
Should we even consider C++ and Win32, given the fact that Microsoft could not support it in the next version of Windows?
Nope
-
Did you happen to catch the Channel 9 video that interviewed the guys on the C++ team? They indicated that Orcas would have increased emphasis on native code development. This does not sound as if they are getting ready to retire native code support any time soon.
-------------------------------- "All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke
Oh, yes, while I didn't view the interview, I read about it in a MSDN blog. That could be one reason to refute the bosses' idea. Thanks!
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
-
And this is one of the issues why I think the app needs to be written in C++, not .NET.
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
-
John Cardinal wrote:
Well to be fair my 39th birthday passed (unnoticed here as usual, I guess I should stop being such a dick if I want people to wish me happy birthday ) a few days ago and I haven't lost any knack or desire for grasping new technologies unlike the bunch of luddites that hang out here.
Well, you are in Canada and all that below-freezing weather slows down your ageing, so your brain age must be that of a 20 year old American :rolleyes:
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. (*Sample chapter available online*) -
Depending on the type of application, you might even consider Ruby. We have written several Ruby GUI apps (using FxRuby) that are well received. 1) For performance and heavy lifting (apps like Internet Explorer, Database servers, networking, high end graphics) - C++. 2) For quick, troublefree, functional desktop apps / batch processing - Ruby. 3) For web - C# / ASP
Vivek Rajan wrote:
We have written several Ruby GUI apps (using FxRuby) that are well received.
Win95 look in Vista?? X|
-
It depends on the app. C# w/ .NET has become a far better, far less dirty "Quick 'n' Dirty" RAD platform than VB ever was. And it's flexible enough that you can still use many non-managed components, if that's a necessity. That said, C++ still wins out if you're looking to go cross-platform. C++ still wins out if you're looking for maximum performance (provided you have the skills to actually take advantage of what it gives you). And straight Win32 wins out if... well, screw that. In the scenarios where straight Win32 wins out, the alternatives are too horrible to even contemplate, much less actively consider alternatives. So, yeah. If you're doing the standard "business app" where the bottlenecks are in front of the keyboard or across the network, C# on .NET. If you're doing a web app, C# on ASP.NET or Java are both good choices.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
Shog9 wrote:
That said, C++ still wins out if you're looking to go cross-platform.
Not true at all, MONO is just about complete for .net 2 and will be soon for .net "3" and it's supported on many different platforms including windows, linux, mac, bsd etc: http://www.mono-project.com/Supported_Platforms[^] And even better you don't even need to recompile your assemblies, you just copy them over and run the program. Can't beat that.
