The world of .NET |
Post Reply |
Author | |
znakeeye
Senior Member Joined: 26 July 2006 Status: Offline Points: 1672 |
Post Options
Thanks(0)
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
Newbie Joined: 02 February 2006 Status: Offline Points: 1075 |
Post Options
Thanks(0)
|
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
Senior Member Joined: 26 July 2006 Status: Offline Points: 1672 |
Post Options
Thanks(0)
|
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).
"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
Groupie Joined: 29 July 2008 Status: Offline Points: 15 |
Post Options
Thanks(0)
|
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
Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 885 |
Post Options
Thanks(0)
|
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.
|
|
Post Reply | |
Tweet
|
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |