The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Todays C++ frameworks

Exploring options for a desktop app - the app is high end CAD, lots of memory, lots of graphics, lots of calculations.

MFC - still works, does what you need, you can use STL/Boost - but seems a step backward and is a pain as soon as you need a dialog to interact in any complicated way.

wxWidgets / QT - if you don't need cross platform are these just adding extra complexity, limited tools, limited developers.

Winforms/WPF - is using it from C++/CLI pratical? Is it easier to just rewrite everythting in c#, what about existing libs - do I end up with the equivalent of a lot of COM objects all shuffling data around.? Is c# upto handling large (memory filling) datasets.

Or can a very interactive high perfomance desktop app be squeezed into a web model? Could I have a c++ engine with a thin WPF front-end talking to it by some local web service mecahnism.
Martin Send private email
Tuesday, January 22, 2008
 
 
You may want to take a look at WPF, particularly if you are not bound by any legacy code.  For an example of what is possible, take a look at the Scripps Institute application developed by InterKnowlogy, a Microsoft partner.

http://blogs.msdn.com/tims/archive/2007/02/14/great-wpf-applications-9-scripps-institute-cancer-research.aspx

I've seen this thing in action and the performance is amazing.  What's more, InterKnowlogy took their application and re-targeted it to understand AutoCAD so instead of manipulating a molecule, you are manipulating an AutoCAD model.

William Leong
Microsoft
William Leong Send private email
Tuesday, January 22, 2008
 
 
Thats very impressive. My visualisation will be done with OpenGL since I need to show point clouds which WPF doesn't handle very well.
The big problem with WPF is C#, either everything needs rewriting or you have to jump through hoops to swap data in/out of C++ libs.
The alternative is to have a C++/OpenGL engine+renderer and have WPF as just a client dashboard, but not sure what would be the best interface between them.
Martin Send private email
Tuesday, January 22, 2008
 
 
I find Wx/Qt to be simpler than MFC and would be the way I would go if you have existing code/want to stay with c++.  If you go WPF go ahead and use C#.  I would consider C++/CLI a different language from C++(you will run into so many odd little differences from regular C++ that you might as well go with the lang that defines the platform, and not have to worry about weird crap ).  There are opengl bindings for C#, I haven't looked into them in a while so I don't know if any currently support WPF or not.
Brian
Tuesday, January 22, 2008
 
 
For GUI I would try to avoid MFC as much as possible. I would use C++ for all backend operations and maybe C# for GUI. MFC is just a waste of time for GUI programming. On the other hand if GUI is already in MFC then why fix something that works (if it works).
Paul de Bugfriend Send private email
Tuesday, January 22, 2008
 
 
We use C++/CLI for a lot of performance orientated work. It's more work for us, but the end result is faster code.
Anony
Tuesday, January 22, 2008
 
 
MFC is getting revamped this year. Don't write it off.
And Get A Haircut
Wednesday, January 23, 2008
 
 
Separating the gui from the app core is a good idea no matter what framework you use, that way you can swap them if necessary.

I'd go with QT if you think the licensing costs are acceptable, it's quite simply the best C++ GUI framework. Very easy to use and intuitive, just read the two available QT books and you're set. It is integrated with the VS 2003 and 2005 build system.
to_be_defined
Wednesday, January 23, 2008
 
 
If it's a fairly straightforward GUI with just buttons, drop-down menus and dialogs you should consider Microsoft's lighter weight WTL as an alternate. MFC is complicated to learn when you need to know exactly what's going on for performance reasons.
Bill
Wednesday, January 23, 2008
 
 
In my opinion, CAD + Web is still a bad idea.

If you develop for Windows and are not required to use Microsoft products, I would recommend you trying Borland Development Studio.
Tony
Wednesday, January 23, 2008
 
 
We make a high-end graphics application, we evaluated the options the OP is looking at, narrowed it down to MFC and Qt.

We chose MFC because of the slow performance of Qt. MFC isn't always simple but there's a load of resources on the web.
MFC fan
Wednesday, January 23, 2008
 
 
I'ld advise a small pilot project (or even just a throw-away prototype) so you can get some real experience with whatever framework you choose before starting a huge project.

Honestly, whether you pick C# with WPF or go for wxWidgets and C++ on Linux, you need to play around with it for a while before you'll even start to really get a feel for how it will suit.


For 3D rendering, any number of open-source 3D engines (OpenSceneGraph, OpenSG, Ogre, are just a few popular options) can provide high-quality, and let end users select from DirectX and OpenGL depending on what actually works best for them. Being higher level than DirectX and OpenGL can make your app much easier to write, as well.

And while WPF has a great many advantages, you might want to consider what operating systems it will work with, and whether or not you'll be working around Vista-only features. Definately a try-before-you-buy option. If things like LINQ were genuinely restricted to specific operating system features I wouldn't mind, but let's be honest here - it's simply an attempt to force people to upgrade their OS in order to use new development tools. (That also means you need to consider what OS versions your target market will realistically be using.)

Wednesday, January 23, 2008
 
 
I was looking at OpenSceneGraph, doing a pilot project to see at how many points we need to go raw OpenGL.
This + performance + data size pretty much forces the engine to be C++.

Current plan is to have a separate 'view' window for the model and free floating tools to interact with it - so there is no need for the client tools to be the same app as the view/engine.
Then I can use anything from wxPython -> Silverlight for the UI client and I have TOTAL separation of GUI/engine.
Ability to quickly create custom UI tools for specific clients is important, native look and feel isn't.

The problem is the best way to communicate between the controls on the UI and the view/engine - when you need to have highly responsive interaction between changing a value in a control and seeing the effect, or manipulating something with the mouse in the view and having the UI controls respond.
Martin Send private email
Wednesday, January 23, 2008
 
 
"MFC is getting revamped this year. Don't write it off."

I'm sure it'll be as good as all the other Microsoft rewrites.  :rolleyes:
Anon
Thursday, January 24, 2008
 
 
> The problem is the best way to communicate ...

I havent tried it but it might not be a problem: for example if it takes 5 msec to do a SendMessage from one process (the UI control with a scroll bar) to another process (which contains the view) when the mouse is moved, this 5 msec delay might not be apparent to the end-user.
Christopher Wells Send private email
Thursday, January 24, 2008
 
 
I think IPC is the way to go. Need to find one that has good async message support at both end, probably use SOAP/WCF.
DBus looks interesting but it's a bit behind on Windows.
Martin Send private email
Friday, January 25, 2008
 
 
One important issue is WHAT PLATFORM/OPERATING SYSTEM, you plan to use, since frameworks are the interaction between the platform, and your application.

Don't try to program in a cross-platform framework, just because its the "hype of today", unless you are sure of your goals. The same goes for open source frameworks v.s. paidware frameworks

Suggestions:

* Windowze:

Borland (CodeGear) C++ V.C.L. framework, way, way ahead of M.F.C. Stay away of .NET (C#, VB, MFC)

* Linux (GNU/Linux, BSD)

GTK+ framework, created to make a photo editing software, became the base for a desktop enviroment (Gnome).

* Cross-Platform

I should suggest Java and SWT, but QT/C++ should be fine. wxWidgets is good, but adds extra layer.

Its good to here someone that knows the difference between a framework and the programming language that it uses. Cheers.

Saturday, January 26, 2008
 
 
Another option for WPF style display from unmanaged C++ is to host the Silverlight 1.0 ActiveX control. You can poke at it from C++, and it takes care of the display parts.
Chris Tavares Send private email
Sunday, January 27, 2008
 
 
"Borland (CodeGear) C++ V.C.L. framework, way, way ahead of M.F.C. Stay away of .NET (C#, VB, MFC)"

I think the only reason why a developer would choose something like C++ over Delphi when they use the same framework is to have the chance to port the application if it becomes feasable/necessary.  Seeing as how Kylix is dead, you will be totally locked into Windows if you choose C++Builder.  There is no migration path to other compilers or platforms.

MFC is portable to other compilers and there is a company I believe which markets a library making it easy to move those applications to Linux easier.

Qt/WxWidgets/etc. all support other platforms, making it all a non-factor.

VCL will give you no choices, only requirements.

MFC is not .NET, and C#/VB aren't the only .NET languages.  C++/CLI is more than capable of tackling the job of desktop application development.
Nate Send private email
Sunday, January 27, 2008
 
 
Where I work we switched to wxWidgets 2 years ago.  At first we weren't sure about where our market might take us so we wanted to make sure our code was not for waste no matter if we were targeting Windows, Linux, Macintosh, or still other platform.

I have worked on products in the past that targeted multiple platforms.  We basically code as much in common C++ as we could and then abstracted the GUIs and system calls the best we could.  We wasted so much time and money coding the same thing multiple times and were constantly debugging and patching all the cross-platform code.

Now with wxWidgets most everything works as advertised.  Of course nothing is perfect.  Any how, wxWidgets is more solid than one might expect, it is a quick learn, has a strong user community, and (most importantly) has stood the test of time.

We also get our projects done in probably one third the time it used to take us and now we rarely have to ship patches because of portability bugs where before at least 25% of our time was taken up with port patches and bug fixes.
Jason5
Tuesday, January 29, 2008
 
 
I have used wxWdigets and wxPython for major commercial apps. It is very nice but it does have the limitations of the MFC style design ie. Pop up dialog - fill in values - close dialog - read back values.
If you want several non-modal dialogs all on screen each making changes that effect the others it becomes tricky.

My main point was that there isn't a default C++ framework anymore, CRUD apps are done in Java or C#/Winforms, any gui apps that needs C++ has to pick wx/QT.

I was exploring the options of using the wonderful new gui ideas in something like WPF for heavy duty C++ apps.

An RTOS i used had a GUI where every control was a database entry and you could set triggers to allow other controls to be notified when one changed or had a specific value - it's a shame that nothing like that seems to have appeared on the PC.
Martin Send private email
Friday, February 01, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz