OK im a newbie to VC++ but I have lots of vb knowledge. Now what do you think is best to use ? MFC or Win32? And Why?
Printable View
OK im a newbie to VC++ but I have lots of vb knowledge. Now what do you think is best to use ? MFC or Win32? And Why?
depends what you want to do
mfc is much easier, win32 is much faster
You should learn the win 32 API first, then, when you know the ins and outs of that you can move on to the MFC if you want to...
MFC is not for newbies, and not for VB converts either.
I love and know alot about API and MFC is easy to me so far its that i have no knowledge of C++ thats why its easier. I can program in Win32 and MFC but only simple things like save to ini, and geting data from the clipboard and using a wide variety of API calls
Why do you say this? I would say its perfect for vb converters because it has a dialog program type that is similar to VB6 and a easy to use class wizzard to generate what you need without over doing alot of un-nescessary codingQuote:
Originally posted by CornedBee
MFC is not for newbies, and not for VB converts either.
If you have no knowledge of C++, as you have said, why are you jumping into trying to create dialogs and windows? Learn the language first...
i know thats what i should be doing but i like getting a feel around visible objects first. Then once i feel comfortable ill start the Core c++ stuff. I have 3 books.
1. C++ For Dummies
2. C For Dummies
3. C++ A Weekend Crash Course
Are these Good? Im currently reading the first book.
I've only bought two programming books in my life, and those were to get class work out of to do my homework. I've never actually read them. So I don't know anything about books.Quote:
Originally posted by JasonLpz
i know thats what i should be doing but i like getting a feel around visible objects first. Then once i feel comfortable ill start the Core c++ stuff. I have 3 books.
1. C++ For Dummies
2. C For Dummies
3. C++ A Weekend Crash Course
Are these Good? Im currently reading the first book.
Take a look at the new question of yours in the "Listbox & Edit Box # Simple ?'s" thread and my answer and you'll see why I say that. If you knew C++ properly then you would have understood my answer.Quote:
Originally posted by JasonLpz
Why do you say this?
even if i knew c++ properly im not a guru and make mistakes just like everyone else. why do you think this formis here? if you dont know, well, its here for all us to help each other . if you want to bother someone who asked a question go ahead but you shouldnt be on this form then. do you think everyone studies and learns the same way you do ..... NOPE!. Everyone is different and should not be judged on what they learn or i should say how they want to learn it so do me a favor and if you're not gonna say something nice and help dont help then. You act like you are the only person here that helps. There are tons of people who help out way more than you.
Easy now. Trust me, he knows what he's talking about, so insulting won't do any good.
I guarantee, you *do* want to learn the language *first*. Don't try and over-reach or you'll just fall flat on your face.
Im not trying to insult him im just saying im thankful very much for his help but ibn ever post he puts what i think is : Mean Comments. I take them badly cuz im just learning and shouldnt be treated like that. I know i should learn the language thats what im trying to do but just in a differnt order
You cannot learn in that order. It is not possible. I know this for a fact, I have *seen* it happen!
Me too. My first book jumped right into MFC. After I had finished the book I knew NOTHING. I buyed a better book and started over.
I know damn well what I'm talking about.
You also have a kinda C/C++ choice here, not only API & MFC.
You can go C code with WinAPI - no runtimes, small executables and a LOT of hard work. Very frugal in terms of size, excellent in speed. This is the way I choose.
You can go C++ and STL, MFC - great, but fat executables are a result. Slight overhead.
MFC does bloat your code greatly, just like VB. From my personal experience, every VB app i created (and nearly every one I used) was unstable. MFC is far more stable than VB, althrough mysterious errors are common indeed.
OK I just wanted to say thanks and that i am reading a c++ for dummies book now. But should i read a
Visual C++ or regular C++
DO i have to learn console programing if i plan never to use it and the coding for it is sort of different than a win32 vc++ program am i right? So should i stick to a VC++ book or my Normal C++ book?
Normal C++. Learn things like the iostreams, the standard library templates, things like that are independent of whether you're using a console or not.
They're also platform-independent.
I agree (for what its worth :p)Quote:
Originally posted by parksie
Normal C++. Learn things like the iostreams, the standard library templates, things like that are independent of whether you're using a console or not.
They're also platform-independent.
I learned very basic C++ in my brief college experience. Then I started working out the concepts of the APIs in C++, so it would be easier to use them in VB.
But I have never found the need to make a visual app in C++ yet, and I am going crazy trying to regrasp the basics of the language for use in non-visual stuff.
ok kool
Can someone but a like list of subjects which should MOST studied aka learned. I know i should studie all of it but. Which areas should i attack with more consentraition and which should i not worry as much about. Thanks
I just wanted to toss in my 2 cents. I was a VB to C convert, and I started to learn MFC first as well. Just like CornedBee said, I did learn some things, but my understanding of how everything worked was really bad. I ended up buying Horton's book and starting over. In hind sight I wished I hadn't wasted my time on MFC at first. That's not to say MFC is evil or worthless, but you should listen to what people have to say. That's just my two cents.
On another note I think your comment of "There are tons of people who help out way more than you." to CornedBee was a bit out of line. I can understand how some of the things he said, and does say, can get taken the wrong way, but on this forum (C & C++) he is the one that helps the most in my opinion. Sure lots of people help out, Parksie, Jim, Kedman just to name a few. I would like to think I help as much as I can (Though I can't ever seem to beat CornedBee or Parksie to most of the questions I can answer). But day after day CornedBee is here helping as many people as he can. Again that is just my opinion.
I've Helped out hundreds or thousands of people here too...
emmm, don't pay attention to my Post # thingie on the side
Oh yeah, Im a VB to C++ Convert, I can say now that now I am
following the 1 and true religion, well, I did try out MFC and
if you're a newbie, I think Win32 is much easier, I might go back
to MFC though and give it a try.
Hope this helps.:)
I have to agree on that one too. I started modifying Visual C++ MFC examples without knowing anything about the langauge, couldn't figure out simple syntax errors. Until I went to www.cplusplus.com and got a decent book, I didnt know a thing.Quote:
Originally posted by parksie
Normal C++. Learn things like the iostreams, the standard library templates, things like that are independent of whether you're using a console or not.
They're also platform-independent.
But, if you want small executables (around 32-64kb), don't use STL. I had a matter where I made a DLL using STL. The dll was 172Kb in size. Now, I rewritten the DLL using C code and it was only 48kb in size. Quit a difference.
@asp: you could tell VC++ to link dynamically to the STL. Would greatly reduce your executable size. (But requires you to ship the CRT dlls with your dll.)
I know that, extra 183 kb to ship though. Still, too much trouble for just a <string> and <fstream>. But I hate extra Dll's and bloated code and <tchar.h> is just fine for me.
If you use MFC, you can do the same.
If you want it really small, then C is frequently the way to go. Which language you choose depends on what you need, and what constraints you're under.
C is great, however, you do have to take a look at the PL (Programming Language) side of the issue. The C language is not as reusable as C++ (C++'s concept of encapsulation allows for code that is slightly slower but more reusable.) This can be made up through the use of _asm subroutines if you want back the speed with change to spare.
In my opinion, if you want small, do not put in MFC and use the ANSI standard libraries (using namespace std;). C++ is fast enough, and you do not have to include all those .dlls
ok but what are the differences between MFC and C++. Like in MFC can you do everything you can do in normal win32 c++
C++ is a language. MFC is a class library written in C++. It's an old class library, which means it doesn't take full advantage of many of the better features of C++ (RTTI, templates).
MFC provides a wrapper around the Win32 API. In parts it's very thin, many member functions are inline and only call their respective wrapped function. In parts it's very thick and introduces new programming concepts into Win32 programming (such as Doc/View).
Because of the extreme number of Win32 API functions there is to my knowledge not a single class library which wraps all of the API (the .Net framework is good, but not complete). To compensate for that MFC gives you enough access to its inner workings that you can overrule and directly call API functions. The resulting downside is poor OOP design.
So you can do everything what Win32 allows in MFC, but not everything with MFC.
MFC does bloat your code greatly and mysterious errors appear. For example, I could'nt get CFile class to work, in the same function the dialog box was called. I have tried everything and ended up using <fstream>.
Never had that problem. And the bloating isn't even that bad. Take a look at Edit++:
Uses MFC, statically linked, needs no runtimes. Has an extreme amount of cool features. The exe is 1.2 MB large. That's not much, considering how many features the app has.
I suppose if the author linked dynamically to MFC the exe would shrink to less than 400k.
I try to limit the size of the software I work on. My current project would weight less than 200kb.
I've been using VB for the last 3 or so years before that I used DOS based C for about a year. This last few weeks I have been learning C++ MFC using SAMS Teach Yourself C++ in 21 days.
The tutorials are easy and I can relate to them because of the visual interface, the problem is of course I am not really learning about the structure of the C++. To get round that I am using the Forger tutorials from http://www.cprogramming.com and DEV-C++ when I am at home in my spare time..
I would really prefer to learn Win32, I like to know what I am doing.
Why should we care what the size opf our programs are? If i make a program thats 3MB i will be proud because i know i did alot of work and the program will have cool feature and 3MB is so tiny. Comapre that to a cd which is usually the shipping or selling method of a program
What about downloading from the net? What about machines with low memory? What would happen if *everyone* did this?
I have 512mb in here, and I plan on keeping as much as I can for *data* rather than program code.
That's not the point here. Program bloat and huge executable sizes give him great personal satisfaction for programming.:pQuote:
Originally posted by parksie
What about downloading from the net? What about machines with low memory? What would happen if *everyone* did this?
I have 512mb in here, and I plan on keeping as much as I can for *data* rather than program code.
P.S. Jason: just a little joke at your expense.:D
Looks like I'm the only one who voted for MFC in this poll.:(
Maybe it is because the programs I wrote, are quite simple, I felt that, for simple programs, MFC is faster (in development). For larger and slightly more complex programs, both Win32 and MFC take equally long time to develop and one would need to know how the messaging system works.
if you only have 512mb you need to get more space because not every program is not 1 mb or less. I know your not planing to do much with that pc. I on the other hand wish i can fill mines up. I have a 120 gig hard drive(western digital) and have aroung 50% left aka 60 gigs. Thats only because i have lots of music and such. but the point is that if you have a pc and plan to download you must have enough space and if you dont free some up or buy some more. Im not saying yuo need a huge hard drive but its not up to me really if a user wants a program they will have to meet MY requirements. not me meeting theres am i right?
I have 80gb of HDD space. I was talking about RAM :)
That's not true.
First, a lot of people still use 56k (like me :) ). Therefore, if you create a program that is 3MB in size, it's going to take a long time to download.
Second, if you are developing for industry, you have to meet the general public's requirements, not yours. The "its not my fault that your system does not meet up to my requirements" can be turned back against you to "its not my fault that your program is big." This is bad for business.
Thirdly, if your program is bloated to look big, then you look like a hack (and not in the good way either.) Always program as efficiently as possible becasue what you can reuse from your previous programs helps you on future programs.
I am not saying that if your program is big after you optimized and such and you are still eating up a lot of resources that you have to limit size. I am saying that you should utilize good programming techniques and try to make your program as efficient as possible.
Tell that to a dialup user like me. You can have your pride...I'll go with a 500-1000k alternative.Quote:
Originally posted by JasonLpz
Why should we care what the size opf our programs are? If i make a program thats 3MB i will be proud because i know i did alot of work and the program will have cool feature and 3MB is so tiny.