I need help to start VS C++/MFC , can u tell me any books or tutorials which starts from basic.
thanks
Printable View
I need help to start VS C++/MFC , can u tell me any books or tutorials which starts from basic.
thanks
Did you read this sticky link at the top of the forum?
http://cboard.cprogramming.com/windo...ing-links.html
By "basic", do you mean from not knowing C++ AT ALL, or from knowing a reasonable amount of C++, but not knowing anything about Windows AT ALL?
As far as i observed, it is better to start from standard win32 api,understand it basically, and then pass on to MFC. If you want a tutorial for win32, here's one:
Forger's Win32 Tutorial
(also mentioned on the link Salem gave)
Nonsense. Win32 should be avoided at all costs.
Ummm... Exscuse me? Did I hear that correctly?Quote:
Originally Posted by Elysia
More than 90% of the world works on Windows and something like 75% of that is 32 bit versions; XP which still holds a more than 45% market share is nearly 100% 32 bit versions. XP-x86-sp3 remains the OS of choice for multimedia intensive applications such as home theatre systems.
Win32 and Win32 API programming is going to be around for quite some time to come...
I think Elysia meant pure Win32 code. It is not for the faint of heart and while it is not all that hard it does become quite ugly and cumbersome.
VirtualAce brings home the point. There is no reason to use a pure win32 approach.
Lets just give an answer to ednan's question and leave choosing from win32 or mfc to him.
I've found another tutorial on win32:
The Winapi (C Win32 API, No MFC) tutorial
It's easier to start compared to the Forger's, but less detailed.
And if you still want learn to learn MFC first, here's a tutorial on the topic:
http://www.codersource.net/mfc.aspx
Oh my... I think we're going to disagree on that one.Quote:
Originally Posted by Elysia
I work Windows API all the time. I very seldom use third party libraries, not even MFC, and while I will grant that it's a bit more work, I don't find it to be either ugly or cumbersome.
You're a C programmer. What do you expect?
LOL... Lets see now... which of several ways should I take that? :confused:Quote:
Originally Posted by Elysia
I'm working on C++, rather slowly because I have a few projects to finish before I climb right in but I don't see a compelling reason to work at any higher level than I already do...
But your roots are that of C. It's where your mindset is. It's how you look at the world. Everything that strays from that is biased in some way. Isn't it?
I am the same, but I see everything from the C++ perspective.
So the point is, since you are used to working with it and is a C programmer at heart, it would be nice for you. But in reality it's horrible, difficult and a menace. It requires years of experience to use properly, and even then, it's entirely possible to make numerous mistakes. Not a very friendly environment.
Frameworks--especially C++ frameworks since C++ allows for more things than C--cut down on this. A lot.
You know, the capabilities of c++ can have a bad effect on people. For example, Elysia, you can't understand win32, you find it too complex. Just because win32 was written in c, you are closed to new ideas about it. So i'm starting to think that c++ takes the ability of complex thinking from you.
And there is no need to insult programmers working on a specific language. C++ might be better, but C alone does the job, too.
I suppose there is a point there... although my roots are in Pascal, not C. If there was an up to date version of pascal with full winapi support and unicode support, I'd be there in a heartbeat... But there isn't, Borland killed it.Quote:
Originally Posted by Elysia
But I fail to see how a "framework" consisting amost entirely of wrappers around WinApi functions does anything except make the end-user code bigger and slower.
For you as a programmer they will make life easier but that's not we're after, is it? Shouldn't we be mostly concerned about handing the end user the best, most efficient code possible; no matter what language we write in?
I am well versed in Win32. To a degree anyway. It's horrible. It's complex, and it's disgusting. Not only because it's pure C, but because of its complexity.Quote:
Originally Posted by new_in_c++
This isn't about C or C++: if you use C, then go ahead, use the API. It might not be too horrendous. But to a C++ programmer, the API is horrendous. It will create bugs, and it will create substandard code for the language. And that is because C++ has tools which C does not, and the API can obviously not use those.
A prime example are handles. They must be closed properly. So you must call CloseHadle or relevant functions. But what if you forget? C++ can take care of that for you. But you'd have to write wrappers for that yourself. Or use a library which handles it for you.
Yes, the end user is what matters. And how much longer development time and bugs will you create because you use the API instead of a framework that handles most of the work for you?Quote:
Originally Posted by CommonTater
The point of wrappers and frameworks is to reduce complexity. It will create an overhead, yes. But it will also reduce development time to achieve something and because it reduces complexity, it reduces the chance for bugs, which means less buggy software and a shorter development cycle.
You're saying it yourself, you find it too complex, because you are a c++ programmer.Quote:
Originally Posted by Elysia
If handles are that hard for you, maybe you should go back to VB.
What i am trying to say is programming in other libraries are like sewing with a hand made of stone. For example Win32 allows you to close handles whenever you want, and the way you want, not the way your library wants.
So, complexity is a price which HAS to be payed by any programmer in order to achieve flexibility.
Yes, yes, you may go back to VB since you desire it so.Quote:
Originally Posted by new_in_c++
And it creates bugs. Bugs which you can live without unless you really need the flexibility which only in about 0.000001% of the cases.Quote:
What i am trying to say is programming in other libraries are like sewing with a hand made of stone. For example Win32 allows you to close handles whenever you want, and the way you want, not the way your library wants.
No one argued that.Quote:
So, complexity is a price which HAS to be payed by any programmer in order to achieve flexibility.
Actually I think I agree with Elysia on one point... They are different mindsets. But I seriously doubt one is better or more valuable than the other. I would think it a mistake to apply any scale of worth...Quote:
Originally Posted by new_in_c++
Plus, knowing Elysia a bit... I'm guessing she's at least moderately familiar with WinAPI...
That said... I am no fan of RAD systems (Rapid Application Design). Delphi, which was really just a mass of units for Pascal used to make me want to hurl after working in Pascal for nearly a decade before... The language suddenly went from small, efficient and fast, to massive, cumbersome and prone to untraceable errors. And it didn't get any better with age.
I will agree with you that RAD systems often can and do have negative impacts upon a programmer's skillset... we all tend to get lazy and RAD is just an open invitation.
For that matter, new_in_c++, I am wondering if you are aware of what the word complex means. Have you worked on libraries in C++? Of big templates systems? Meta template programming? I dare say it's pretty complex. And yes, I have done it.
And you know algorithms? They can be pretty complicated, too. Yes, and I have written lots of them.
I don't tend to shy away from complexity. I tend to embrace it.
It has also been shown that you can write a full-fledged GUI library in pure C that isn't nearly as complex as win32 API. Just look at GTK+ for an example. In my view Win32 API is horribly bloated and anything that abstracts it away is better really.
Elysia, me amiga... APIs do not create bugs... Programmers create bugs. It's a matter of attending to details...Quote:
Originally Posted by Elysia
Then you find and fix your error.Quote:
A prime example are handles. They must be closed properly. So you must call CloseHadle or relevant functions. But what if you forget?
So, to be clear... your logic is that you are reducing complexity by introducing complexity?Quote:
Yes, the end user is what matters. And how much longer development time and bugs will you create because you use the API instead of a framework that handles most of the work for you?
The point of wrappers and frameworks is to reduce complexity. It will create an overhead, yes. But it will also reduce development time to achieve something and because it reduces complexity, it reduces the chance for bugs, which means less buggy software and a shorter development cycle.
So how do you minimize the bugs the programmer create?Quote:
Originally Posted by CommonTater
No, you don't produce them in the first place.Quote:
Then you find and fix your error.
Depends on what you view as complexity. If 3rd party libraries are complexity, then yes.Quote:
So, to be clear... your logic is that you are reducing complexity by introducing complexity?
If not, then...
Since no one is giving any effort to answer the main question i'm continuing to give tutorial links:
C++ Win32 API Tutorial | Inferno Development
This is a short article written on the basics of win32.
Free programming ebooks - java ebooks - linux ebooks - c, c++ ebooks
I think you can find some ebooks on the topic from this site.
Visual Basic 2008 Tutorial
And this one is for you Elysia :) Just kidding. I know a C++ enthusiast like you won't try another language easily.
Ummm... no offense but you may want to give that some thought... GTK+ and other such toolkit libraries are, for the most part wrappers applied over and around WinAPI functions. By their very nature that will be both bigger and slower than direct WinAPI calls...Quote:
Originally Posted by Shakti
By becomming a better programmer.Quote:
Originally Posted by Elysia
It's about improving your craft, not avoiding it's difficulties.
That is not the point.Quote:
Originally Posted by CommonTater
The point is that it reduces complexity.
That is only part of the equation. Even the best of programmers cannot avoid all pitfalls and bugs.Quote:
By becomming a better programmer.
It's about improving your craft, not avoiding it's difficulties.
And btw, it's "its" in this case, not "it's".
Then i'm surprised to hear you hate win32. An "ambitious" programmer like you should have "embraced" that too. Instead, you are making "newbie" programmers run away from win32, telling them how disgusting win32 is.Quote:
Originally Posted by Elysia
It is, because in the end, the reason I embrace complexity is to reduce it. A library must be flexible. But it must also be easy to use. Win32 is not. It's a failure.
See, that's where we are arguing a crossed purposes... At some point all these extensions, wrappers, frameworks and libraries have to go back to the OS... You are effectively speaking to the OS through a translator. Not only is this more complex, I should think it would be far more error prone. That the wrapper may fix its own mess, doesn't mean it's less complex or more efficient. It really only means it's easier for the programmer.Quote:
Originally Posted by Elysia
Now, on THAT we are definately going to disagree.Quote:
That is only part of the equation. Even the best of programmers cannot avoid all pitfalls and bugs.
Sigh... I always get that wrong... :(Quote:
And btw, it's "its" in this case, not "it's".
And that is the point. We must create something complex and tame it in order to use it easily. Such is the way for all things.Quote:
Originally Posted by CommonTater
Computers... very complex beasts. Very hard to make. Yet, once made, so easy to use. And so valuable a tool.
You can't escape reality...Quote:
Now, on THAT we are definately going to disagree.
Think of it this way:Quote:
Sigh... I always get that wrong... :(
"it's" is a shortcut for "it is". So repeat the sentence to yourself. Does it make sense for it to be spelled with "it is" or "its"? For example,
This is a pen. Its color is red.
This is a pen. It is color is red.
Which one makes sense?
Fighting is meaningless at the moment, as no body is going to change his/her mind.
But are we the ones who should be concerned about ease?Quote:
Originally Posted by Elysia
Again... is it not our job to do the complex work of making it easy for the end user?
LOL... Not even in C++ with a gazillion bytes of framework...Quote:
You can't escape reality...
As I said before, the more complexity you put in your application, the more bugs there will be. Yes, it is our job to abstract it from the user. But it is also our job to make the user happy.Quote:
Originally Posted by CommonTater
If there are already tools available, why not use them?
If you had a choice between using a screwdriver and an automated electric screwdriver, which would you use? Clearly, the electric one would allow us to get the job done faster, and with more accuracy.
One can make the same argument about WinAPI...Quote:
Originally Posted by Elysia
If the OS already provides you the tools you need, why not use them?
Given the number of times I've pulled out my trusty Philips screwdriver and tightened every bolt and screw installed with automated screwdrivers on Chinese production lines... I'm having a very hard time answering that one... (Seriously... it seems that everything I work on these days is made in China and every last screw is undertightened.)Quote:
If you had a choice between using a screwdriver and an automated electric screwdriver, which would you use? Clearly, the electric one would allow us to get the job done faster, and with more accuracy.
Because it's inferior.Quote:
Originally Posted by CommonTater
"Hey, look, it's cold outside! Let's store our food outside instead of the freezer!"
It is a wrapper yes, but who says something like that couldn't have been implemented instead of the way winapi is currently implemented? That is the huge difference. Winapi is probably a wrapper over kernel-code anyway so the whole wrapper point really doesn't stick. Especially combined with my second point below.Quote:
Originally Posted by CommonTater
Speed isn't really an issue either, since alot of the time spent in a win32 application is idling just waiting for messages anyway.
Edit: I see alot of my thoughts have already been conveyed by Elysia after my initial post.
Second edit: I can't really see how one can argue that a more complex library should be used when there are other better designed libraries providing more functionality in a form that is much easier for the programmer to handle and use. "The best tool for the job" is an expression often used by programmers, and it applies to libraries aswell. In todays day and age WinAPI is losing out to other libraries that are better designed for todays usage, both in easy-to-use when doing the initial programming but also in maintaining a program.
A huge part of a programs life-span is maintaining it and must be taken in account when making decisions. I do not and never will beleive a pure WinAPI application is easier to both program the initial application and to maintain, than a program written in a more modern library.
Consider that most of your frameworks --wrappers, etc.-- actually call WinAPI functions... If the WinAPI is so inferior, how can your frameworks possibly be any better?Quote:
Originally Posted by Elysia
A house is no better than the wood it's made from...
You misunderstand what I mean by inferior. It isn't that WinAPI produces inferior results--it does not. It is inferior in such a way that it is difficult to use to attain the correct results. The libraries simply the getting results right part.
Because the wrapper exposes the relevant parts in a more programming-friendly environment that allows the programmer to use the underlying library in an easier way to produce more robust application less prone to bugs. An open-source library (mentioning open-source because many of the biggest GUI libraries are opensource) is probably peer-reviewed many times harder than any code written by a programmer at a company.Quote:
Originally Posted by CommonTater
With your logic C isn't really useful since its just a "wrapper" for assembly, and assembly is just a wrapper for binary code anyway so by your logic binary code is the way to go when programming.
A house is no better than the wood it's made from, but a house with a crappy blueprint and layout is still crap, no matter how good the wood is.
Actually WinAPI is a collection of DLLs. Some of the functions will, indeed be kernel calls, but most are just library functions... much like your wrappers.Quote:
Originally Posted by Shakti
I'm not saying you don't have a point... you do.Quote:
I can't really see how one can argue that a more complex library should be used when there are other better designed libraries providing more functionality in a form that is much easier for the programmer to handle and use. "The best tool for the job" is an expression often used by programmers, and it applies to libraries aswell. In todays day and age WinAPI is losing out to other libraries that are better designed for todays usage, both in easy-to-use when doing the initial programming but also in maintaining a program.
However; --and this is where I get a little giggle every time this comes up-- WinAPI is, itself, merely a set of libraries.... In effect you're arguing "My toy's better than your toy" and I think we both know the obvious retort to that... "Is NOT"... "Is SO"...
Y'know what, I can make the same claim in reverse... But in reality it's a question of familiarity. I've seen WinAPI programmers who look at third party libraries in disbelief... and next to him is a library fan looking at WinAPI in disbelief... Both are overwhelmed by what they are not familiar with...Quote:
A huge part of a programs life-span is maintaining it and must be taken in account when making decisions. I do not and never will beleive a pure WinAPI application is easier to both program the initial application and to maintain, than a program written in a more modern library.
Now that I can agree with. The libraries do simplify your job somewhat.Quote:
Originally Posted by Elysia
But you started off claiming that WinAPI itself introduced bugs into programs... Apparently not thinking what lies underneath your wrapper libraries...
Yes, and I still claim that using WinAPI in its raw form introduces bugs into programs. More so than using 3rd party libraries.Quote:
Originally Posted by CommonTater
Take my word for this... You do not want to get me started on Open Source projects... Let me just remind you of the old saw: "Too many cooks spoil the broth".Quote:
Originally Posted by Shakti
Don't try so hard... You're point is heard... I disagree but I have definately heard you.Quote:
With your logic C isn't really useful since its just a "wrapper" for assembly, and assembly is just a wrapper for binary code anyway so by your logic binary code is the way to go when programming.
A house is no better than the wood it's made from, but a house with a crappy blueprint and layout is still crap, no matter how good the wood is.
Shall I repeat my previous point about where bugs come from? :pQuote:
Originally Posted by Elysia
Yes, it is hard to argue in any other way really. But I think you will find more programmers switching from WinAPI to some other library that wraps it than you will find programmers switching from a wrapping library to WinAPI. I know it's a crappy argument really but in my mind this says something about WinAPI in comparison with the other libraries.Quote:
Originally Posted by CommonTater
The difference I think is that if they were both to use the other (library fan use WinAPI and the winapi fan use the library) for say a week I think in many cases the library fan would go back to the library and the WinAPI fan would probably also concede that the library is easier (better).Quote:
Y'know what, I can make the same claim in reverse... But in reality it's a question of familiarity. I've seen WinAPI programmers who look at third party libraries in disbelief... and next to him is a library fan looking at WinAPI in disbelief... Both are overwhelmed by what they are not familiar with...
Humans like to do things the easy way and once you get somebody to try the easy way its easy to stick with it. The reverse can not be said.
No, they are not logical.Quote:
Originally Posted by CommonTater
Yes I think open-source has problems, too many cooks can definately be one of them. That doesn't mean there are some seriously peer-reviewed open source libraries that are better than the underlying library they wrap.Quote:
Originally Posted by CommonTater
Not trying hard at all really.Quote:
Don't try so hard... You're point is heard... I disagree but I have definately heard you.
Bad programmers produce bugs yes, but is that a reason for not making the life as easy as possible, and give and let programmers use every tool available to produce bug-free code?Quote:
Shall I repeat my previous point about where bugs come from? :p
Just because programmers create the bugs doesn't mean we shouldn't provide any tool available to prevent that. And a library that is less prone to produce buggy code is one of those tools.
It also says quite a bit about programmers, too...Quote:
Originally Posted by Shakti
Nobody's going to blame them for taking the path of least resistence, it's done all the time. But there is no denying the impact on the craft... A lot of "dumbing down" as programmers increasingly have less and less understanding of the systems they motivate...
In the mid-1980s when I began to incorporate computers into my professional life (instead of the hobby they'd been until then) the big grumble about Programmers was "They just don't seem to understand the hardware"
Now it's fast becomming: "They just don't seem to understand the software..." :eek:
It means they are working in a field they should not be.
I don't think there is a correlation betwean how good a programmer is and what library they use. Just because a person chooses to use a library that is easier than the native way does not mean they can't learn the native way and become very good at it either. Granted it will probably take more time (only natural, more complex means more time needed to be speant). After all, they had to learn to use the easy library, so what is there to say they can't learn to use the native way?