programming

[ddudics]

Hey Marc,

I was just wondering... what do you program in? Visual Basic? Visual C++? Visual C#?

If you program in Visual C++ or C#, what programming route do you take? MFC? Win32 API? .NET?

[Marc G]

I'm using Visual C++ with MFC interleaved with plain Win32 API calls. The DLLs used by Wallpaper Cycler, ShellEnhancer and FileEngineer are written in Visual C++ but with plain Win32 API calls and no MFC.

PS: I have taken a quick look at C# and the .NET framework and I must say I really like it. I might use it in the future It is especially usefull for RAD.

[ddudics]

do you find it easier to use the MFC?

I've always leaned more towards win32 api. But i was looking at the MFC recently and it seems to make database programming very easy.

Also, how do you create the main window(s) for your applications, with MFC or with the Win32 API calls? Why do you prefer that method over the other?

[Marc G]

I find it easier to use MFC than to use Win32 API for everything.
MFC takes a lot away from you. For example, you don't have to write your own messagepump. MFC makes your code cleaner, because it doesn't require you to write a windowproc function with 1 big switch statement. For example, to display a modal dialogbox, you just create your dialog in the resource editor, use classwizard to add a class for that dialog (which will contain very little code), then just do

Code: Select all

CMyDialog dlg;
dlg.DoModal();

to display the modal dialog box. This is much faster than using the Win32 api.

And like you said, MFC contains lots of extra usefull classes. Classes for database programming, for internet access, string manipulation, file access, GDI objects (which automatically destroy the GDI object when the GDI object goes out of scope), synchronisation objects (mutexes, critical sections, ...), dynamic arrays and much more.

All my stuff related to creating/displaying windows is done in MFC, because like I said above, it is easier. Why would you want to spend more time using the Win32 API each time you want to display a window when you can quickly display the window with MFC? MFC is a nice wrapper around the Win32 API, so I see no reason not to use it.

Also, the nice thing about MFC is that it's nicely integrated into the Visual C++ IDE.

Of course there are other wrappers available to, which I have not yet tried though.
Microsoft has another wrapper called WTL. Then there is wxWindows, which appears to be a nice cross-platform GUI library.

[ddudics]

well... know that i think about it... i guess you're right. computers are faster now so they can run applications created in MFC just as fast as they could run applications that were created in win32 api.

i guess that's something i should consider. and wow... i didn't know about wxWindows. I'm gonna check it out.

thanks.

[edit] FYI. wxWindows is now wxWidgets

[Marc G]

well... know that i think about it... i guess you're right. computers are faster now so they can run applications created in MFC just as fast as they could run applications that were created in win32 api.

Mmm, why do you think that applications written in MFC are slower than ones written in plain Win32 API?
I do not agree with this. Perhaps if you measure the GUI response etc with precision timing functions, then you might be able to measure some small speed penatly (I am not even sure of this though!), but it would only be measurable with precision timings and not noticeable by a human user.
I mean, if you write in plain Win32 API style, you have to create your own message pump, a Windows program cannot work without it, and you have to create your own windowproc processing messages etc. MFC also does this, but it does this for you. Also, MFC is heavily used/test/tweaked over the years.
So i really don't think there is a big speed penalty.
If you know a nice way to measure performance difference between MFC and plain Win32 API, then try to write a little benchmark and lets see what the results are

FYI. wxWindows is now wxWidgets

Ah, they renamed it ... but the domain is still wxwindows.org

[ddudics]

Mmm, why do you think that applications written in MFC are slower than ones written in plain Win32 API?
I do not agree with this. Perhaps if you measure the GUI response etc with precision timing functions, then you might be able to measure some small speed penatly (I am not even sure of this though!), but it would only be measurable with precision timings and not noticeable by a human user.
I mean, if you write in plain Win32 API style, you have to create your own message pump, a Windows program cannot work without it, and you have to create your own windowproc processing messages etc. MFC also does this, but it does this for you. Also, MFC is heavily used/test/tweaked over the years.
So i really don't think there is a big speed penalty.
If you know a nice way to measure performance difference between MFC and plain Win32 API, then try to write a little benchmark and lets see what the results are

Well... i just figure that it would be slower. I mean, if you think about it, the MFC are just wrapper funtions; so wouldn't they just be calling the same win32 api funtions? So, then theoretically, wouldn't it take less processing power to just call those functions directly instead of calling functions that call functions?

Ah, they renamed it ... but the domain is still wxwindows.org

Yeah... i saw that too

[Marc G]

Well... i just figure that it would be slower. I mean, if you think about it, the MFC are just wrapper funtions; so wouldn't they just be calling the same win32 api funtions? So, then theoretically, wouldn't it take less processing power to just call those functions directly instead of calling functions that call functions?

Yes, of course, you are right, but like you said: theoretically. Like I posted in my previous reply, the difference in speed would probably only be measurable with precision timings and certainly not by a human user.

[ddudics]

hmm... well... i guess yur right.

thanks alot!

[Marc G]

You're welcome

[ddudics]

Okay... what do you think about using the .NET architecture instead of or with MFC? And what about C#? Is that worth learning?

[Marc G]

The .NET framework is pretty powerful and is being used more and more often by companies, so it is worth looking into it. Note that the .NET framework has nothing to do with a programming language. You can use the framework from VB, C# but also from C++. So you can for example use the pretty powerfull Image and Bitmap classes from the .NET framework in your MFC projects.
In my opinion, it is certainly worth learning how to use the .NET framework and learn what you can do with it.

About C#, I did take a look at it a while ago, and my first impressions were positive. It is really usefull for RAD (Rapid Application Development). With C# you don't have to worry about several things that you know from C++. For example, C# has a garbage collector (beter than the Java garbage collector). This means that the programmer doesn't has to manage all the memory. When an object isn't reachable anymore, the garbage collector will automatically delete the object.
Also, C# uses a just-in-time compiler which has the possibility to optimize the code specifically for your system. The optimizer might for example use some extensions like SSE/MMX if it detects these extensions. The result of the just-in-time compiler are stored, meaning that the second time you run a function, it will already be compiled, so it runs much faster.

Now, is it worth learning C#? It certainly is, but it depends a bit on your situation. If you don't know a programming language and you have to start from zero, I might recommend learning C# first. That way, you learn a state-of-the-art programming language with all OOP-goodies and at the same time your learn the .NET framework, because it is heavily used in C# programs.
In your case, you already know C/C++, so perhaps it might be more usefull to first take a look at the .NET framework using C++. The .NET framework will make a lot of things easier, including database programming, image processing, drawing, internet access, xml, security, ...
But, if you don't mind learning another language and you have some free time, then you might as well take a look at C#. Try to make some toy-problems in it. You will quickly find out if you like the language or not. And learning another language is always nice if you want to apply for a job; adding one more language to your cv

[ddudics]

Cool. thanks!

And, yeah... the main reason why i've been considering using C# is because i keep forgetting when to use . and -> when accessing pointers (i used to know very well when I was emersed in C++ a while ago, but it's been like 4 years or so).

[Marc G]

Yes, no need to worry about . and -> in C#