The world of .NET

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   Your Windows GUI project starts today, and you are to choose technology. What do you choose?

.NET, MFC, QT or other? Please motivate your answer! 

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
znakeeye Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 26 July 2006 Status: Offline Points: 1672	Post Options Post Reply Quote znakeeye Report Post Thanks(0) Quote Reply Topic: The world of .NET Posted: 08 December 2009 at 7:19am
	Your Windows GUI project starts today, and you are to choose technology. What do you choose? .NET, MFC, QT or other? Please motivate your answer!

ABuenger Members Profile Send Private Message Find Members Posts Add to Buddy List Newbie Joined: 02 February 2006 Status: Offline Points: 1075	Post Options Post Reply Quote ABuenger Report Post Thanks(0) Quote Reply Posted: 09 December 2009 at 4:09am
	MFC. Qt doesn't have all the controls and look & feel you need for a native Windows app. I strictly separate the UI from the rest of the code. Result is less than 10k lines UI code and over 100k portable lines C++ code. So in my eyes only poor developers are making such a drama about the language and framework. I have my own base classes. Portable threading, sockets, serial ports etc. 20k lines. Makes the rest a breeze. For poor developers who don't care about portability, separation etc. I would choose .NET ;)
	Codejock support

znakeeye Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 26 July 2006 Status: Offline Points: 1672	Post Options Post Reply Quote znakeeye Report Post Thanks(0) Quote Reply Posted: 09 December 2009 at 8:09am
	I agree with you. I think C++/MFC separates the elite from the poor programmers. To get it right, you have to know what you're doing (which is a great advantage when making software :P). My favorite: http://msdn.microsoft.com/en-us/magazine/dd861344.aspx "However, if you want to develop high-performance and high-quality commercial applications, you'll still look to C++ and native code to deliver that power."

cjrobindch Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 29 July 2008 Status: Offline Points: 15	Post Options Post Reply Quote cjrobindch Report Post Thanks(0) Quote Reply Posted: 09 December 2009 at 9:47am
	Visual C++ 6.0 + MFC + CJ. I have an app family with around 480k lines of code (heavy crypto, tcp/ip, threads, database, automated installers, etc, etc). Couldn't imagine what 480k lines of .NET would be like to manage, nor how fast the app would be.
	Product: Xtreme Toolkit Pro 15.0.1 Platform: Windows 7 (32bit) Language: Visual C++ 6.0

rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 886	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: 09 December 2009 at 12:36pm
	MFC. We talk directly to high-end OpenGL graphics cards. We have well over ten million lines of c, c++ and MFC code in the bank. Our graphics and memory requirements are huge. .NET has its place. Creating and consuming web services is easy but I had to use MC++ to do so (has .NET finally added structured storage support?) Interacting with databases is also pretty easy. Our (COM) app also has in-proc .NET components (add-ins) that use our API. This includes inserting WinForms into our app (docked in a C++ CJ docking pane). But managing the life-time of COM objects is a nightmare in .NET. I'm not talking about the CCWs but the actual COM objects the CCWs grab hold of and pretty much refuse to release. ReleaseComObject and FinalReleaseComObject are misnomers. The calls only release a CCW and not the actual COM object. Forcing the release can be done by careful manipulation of the GC object but even then there is no gurantee that all collectible objects get cleaned out. MS did help by not running GC when a process terminates (need a more recent .net runtime for that as the 1.x framework has not been modified afaik). The decision boils down to exactly what your app will be doing.