Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations MikeeOK on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

programming variants

Status
Not open for further replies.

LyMc

Programmer
Jun 3, 2003
84
US
A more philosophical question this time.

There are lots of variant C/C++ programming libraries in MS for windows gui programming. There's Win32-style (as used by Petzold in PW5), MFC, ATL, "managed" coding and others, which all seem to overlap greatly. Looking up an API on the MS Visual Studio and be a search through many different libraries with similar but differing calls. Why are these there, which situations call for which variants?
 
There are many ways to programming an application: it depends on what you're looking for.

Initially, life began with the SDK. In the days of Windows 3.1, the SDK came with a box of books which took up about 3' of shelf space. Most of the info was in the Programmer's manual which listed the routines in alphabetical order. Unless you knew the API inside out, it was difficult to find anything. Also, like all APIs, the parameters weren't totally consistent. Sometimes, when all else fails, the SDK calls will work.

Then MFC came along. It was a bunch of OO wrappers for the SDK. This was better organized and a lot easier to program than the SDK. The only problem was that the whole of MFC lived in one library which was absolutely massive. An SDK program of 100K would compile into an MFC program of 500K! Good for rapid development at the cost of humungus programs. This is very integrated into COM/DCOM.

Then ATL/WTL came along. These are C++ templates, similar to MFC but without the overhead. So we're back to SDK sized programs again. However, the penalty is in the templates. Many of them are quite complex and, to reduce the amount of code, 2-3 letter variable names like _r and _t1 are used, making them extremely difficult to follow. However, if you are not bothered abou templates, it is as good as MFC but generates less code.

One of the big problems with programming in general is memory problems. Instead of worrying about the problem, developers spend a lot of time tracking down illegal memory accesses etc. So in comes Managed Code. This is basically OO with reference counting. You don't have to worry about freeing the memory: the OS will do it for you when the objects are no longer in use. A bit like Java. Only problem I find with it is that the OS also tends to move stuff about so you can no longer rely on addresses to be fixed. Some people like it some people don't. Even on the latest compiler (VS.net 2003) on a 2.5GHz 1Mb PC, managed programs are a pain to debug.
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Sponsor

Back
Top