API vs MFC

[blackcoder41]

uhm.. i just get back to programming and now i am learning windows programming from this site http://www.winprog.org/tutorial/ so far so good.. then i get to read this http://www.winprog.org/tutorial/apivsmfc.html

just want to know what you think on the author's opinion?

also i just got an old book "programming windows by: charles petzold", is it still worth reading considering the book is old?

~thanks guys

[Incubbus]

API ftw!...

i especially agree with the 4th and 5th paragraph...

i do suggest learning the api first... i already read on some of the microsoft sites, that the mfc is getting kind of old and won´t be improved in future versions: but this is kind of strange, since they done it with the new VS2010...

[blackcoder41]

maybe microsoft really want .Net Frameworks to be the new generation GUI

[chrisname]

Neither. POSIX API.

[helios]

POSIX API

lolno

[Disch]

crossplatform widgetry libs ftw

EDIT:

Also...

But isn't MFC easier? In a certain sense it's easier in that many common tasks are done for you, thus reducing the amount of code that you need to actually type. However, less code does not mean "easier" when you don't understand the code you DO need to write, or how all of the code that is there to support you actually works. Generally beginners who use the wizards to start there applications have no idea what most of the generated code does, and spend a great deal of time trying to figure out where to add things, or what changes to make to acheive a certain result. If you start your programs from scratch, either in the API or with MFC, then you know where everything is because you put it there, and you will only use features that you understand.

I 100% disagree with his mentality here.

I started with MFC and "worked my way down" to understanding the underlying process.

1) It probably made it tons easier

2) I was able to start making the kind of programs I wanted to make right away. Like within the first few weeks of learning C++ -- I was already making simple dialog based adventure games. I didn't have to dick around with the console or the details of window creation or the message pump or any of that.

WAY more fun. If I had to dick around with the console and a million useless "write a program to simulate an ATM" programs I might've lost interest and my progress would've slowed way down.

3) It didn't slow my progress at all. If anything it sped it up. I learned how to do new things as I needed to do them, without having to learn how to do everything right away.

4) "only using features you understand" as he puts it, sucks for a newbie because you don't understand anything when you're starting out. I say let the API be a black box that just magically works so you can write your programs. If you want to learn how it works later, then research it later after you understand what you're doing a bit more.

[chrisname]

@helios,
Why not? It beats the windows API in most places.
Say we want to create a new thread.

In windows, you use CreateThread:

HANDLE WINAPI CreateThread(
  __in_opt   LPSECURITY_ATTRIBUTES lpThreadAttributes,
  __in       SIZE_T dwStackSize,
  __in       LPTHREAD_START_ROUTINE lpStartAddress,
  __in_opt   LPVOID lpParameter,
  __in       DWORD dwCreationFlags,
  __out_opt  LPDWORD lpThreadId
);

Return value:
- What the hell is a HANDLE WINAPI?
Arguments:
- lpThreadAttributes: What's this? Is it a bitmap? A struct?
- dwStackSize: Ok, fair enough. I don't see why I need to specify this, but whatever
- lpStartAddress: Pretty self-explanatory
- lpParameter: parameter for what?
- dwCreationFlags: no idea what to do with this
- lpThreadId: don't have a clue what this is meant to be

With POSIX, you use pthread_create:
int pthread_create(pthread_t *thread, const pthread_attr_t *attr, void *(*start_routine)(void*), void *arg);
Return value:
- A C/C++ programmer who doesn't know what an int is should be shot
Arguments:
- thread: OK, you don't know what a pthread_t is; but it's pretty easy to find it. Open up pthread.h and look for the typedef. How are you meant to figure out what an LPSECURITY_ATTRIBUTES is? Naturally you'd open windows.h and look for "#define LPSECURITY_ATTRIBUTES" but it might be a typedef.
- attr: again, you probably don't know what a pthread_attr_t is, but at least you know it's almost certainly a typedef. Besides, the man page will inform you that it can be NULL.
- start_routine: obviously a function pointer.


To me, the POSIX API is much, much better than the windows one. I can actually read code that uses it!

[blackcoder41]

I 100% disagree with his mentality here.

I started with MFC and "worked my way down" to understanding the underlying process.

1) It probably made it tons easier

2) I was able to start making the kind of programs I wanted to make right away. Like within the first few weeks of learning C++ -- I was already making simple dialog based adventure games. I didn't have to dick around with the console or the details of window creation or the message pump or any of that.

WAY more fun. If I had to dick around with the console and a million useless "write a program to simulate an ATM" programs I might've lost interest and my progress would've slowed way down.

3) It didn't slow my progress at all. If anything it sped it up. I learned how to do new things as I needed to do them, without having to learn how to do everything right away.

4) "only using features you understand" as he puts it, sucks for a newbie because you don't understand anything when you're starting out. I say let the API be a black box that just magically works so you can write your programs. If you want to learn how it works later, then research it later after you understand what you're doing a bit more.

what a response! and oh if you prefer cross platform libraries, what do you suggest? wx/ gtk+ / QT or something else..

hey guys what do you think about Disch opinion?

[blackcoder41]

i think chrisname hates windows.. LOL..

anyway what do you think about the petzold book? kinda old isn't it? or still worth to read?

[chrisname]

Well... I wouldn't say "hate"... But at the same time, there's only two things I like about windows: it's easy to use and there's lots of games for it. Other than that, I don't like it.

Afterthought: I'm not getting into this argument again, so don't bother replying.

[Disch]

chrisname... all of those answers could be answered by reading the documentation.

You should never use any API function without reading the documentation. Especially where threads are concerned. POSIX is no exception.

But anyway.. .without having checked the documentation... and having actually used CreateThread like maybe 3 times before in my life (many many many years ago), I can tell you the following:

- What the hell is a HANDLE WINAPI?

WINAPI is a calling convention. Granted there's no way to know this from that snippit you posted unless you are semifamiliar with WinAPI.

A HANDLE is just that: a handle. Essentially it is the object that represents the thread.

Handles aren't really that weird of a concept -- they're all over WinAPI. Maybe you're just not that familiar with them?

- lpThreadAttributes: What's this? Is it a bitmap? A struct?

The 'LP' suggests is a pointer to a struct named 'SECURITY_ATTRIBUTES'. Probably to specify things like thread priority and whatnot. Of course if you want to use it you'll have to check the documentation for SECURITY_ATTRIBUTES. If you don't want to use it, you can pass NULL as the bit you posted indicates the parameter is optional.

- dwStackSize: Ok, fair enough. I don't see why I need to specify this, but whatever

Admittedly, that one does seem strange to me as well. But the documentation probably recommends a default value to use.

- lpParameter: parameter for what?

For your callback. Seemed pretty obvious to me. Callbacks are pretty much always bundled with a void pointer for user data. Even the POSIX function you posted has this.

- dwCreationFlags: no idea what to do with this

Same. But if you skimmed the documentation, I'm sure you'd know.

- lpThreadId: don't have a clue what this is meant to be

Well it's an 'out' parameter, and it's named 'lpThreadId', so I'm guessing it gives you the thread ID. But it's optional, too, so you can just give it NULL.

Return value:
- A C/C++ programmer who doesn't know what an int is should be shot
Arguments:

What is the int, though? Like what does it represent? Is it a faux boolean value that tells you whether or not the thread succeeded? Like an error code? Or is it some kind of ID to the thread?

(Yes I know I could check the documentation to see what it actually is. I'm just trying to point out that it's not as simple as you're trying to make it look)

How are you meant to figure out what an LPSECURITY_ATTRIBUTES is? Naturally you'd open windows.h and look for "#define LPSECURITY_ATTRIBUTES" but it might be a typedef.

"Naturally"? Wtf? That's completley unnatural. Who does that?

You don't sift through header files looking for stuff, you read the documentation. That's why documentation exists.

google, msdn, etc.

- attr: again, you probably don't know what a pthread_attr_t is, but at least you know it's almost certainly a typedef. Besides, the man page will inform you that it can be NULL.

How is this any different from SECURITY_ATTRIBUTES?

To me, the POSIX API is much, much better than the windows one. I can actually read code that uses it!

Those two functions are practically the same. The WinAPI version only has 2 extra parameters, one of which is clearly marked as optional.


Actually maybe I counted wrong (actually I didn't count). Is there 3? Maybe that is a little excessive. Still I don't think it's too horrible.

[helios]

chrisname: Thanks, I needed some feeding.

Like Disch said, all those questions are answered in the documentation, but here's a couple conventions the WinAPI uses:
* HANDLE is a generic identifier for system resources. This includes everything: processes, threads, files, GUI controls, etc.
* If it starts with "lp" or "LP", it's a pointer. LPVOID is a generic pointer; LPTCHAR is a pointer to a TCHAR, which is either a char or a wchar_t, depending on whether UNICODE is defined; and so on.
* __in, __out, etc. are #defined as nothing, and are there merely for documentation purposes.

I honestly don't see how the POSIX interface is better, other than taking fewer parameters. Needless to say, the parameters it doesn't take are passed through const pthread_attr_t *attr.
Let's face it: two interfaces for basically the same thing aren't going to be too different.


Finally, yes. Portable toolkits > *.

[blackcoder41]

Let's face it: two interfaces for basically the same thing aren't going to be too different.

agree :)