Am I ready for C++ and MFC ?

[DanLeon]

Dear Experts

I started teaching myself pure C at the beginning of the year by reading books like "K&R The C programming language", "Programming Windows by Charles petzold" and various others, aswell as the internet.

So far I have a fairly good knowledge, I can write GUI apps using the WinAPI. I have a massive interest in network programming and have written a file transfer app. Also a basic chat server/client using the powerful select() call on both unix and windows.

My main weakness tho comes down to two things really, the lack of using structs in my code, obviously I know what structs are but have never written anything which really needs them (apart from the WinAPI structures to pass through functions) I don't write my own, except for example my file transfer app, storing the file name and size in a structure and send()ing it over to the receiving end. I need some ideas on how I can improve this, maybe look into abit of game programming?

The second is string parsing, I sometimes can find this hard using the standard C library, for example filtering out specific lines of text between HTTP tags. I need to improve this aswell any ideas ?

The big question is, am I ready to start learning C++ and MFC ? or do my current skills need to be better ?

[bioHzrdmX]

Hi DanLeon,

MFC is one of the most powerful frameworks out there, it has a great set of classes to do a lot of things, and if you know how, you can expand them to do almost everything.

That is the key to learn MFC: classes. You should have a very good C++ knowledge, also you should fully understand the object-oriented programming paradigms: inheritance, polymorphism and encapsulation. In MFC, you'll be working with objects almost all the time, creating that, destroying that, overloading procedures and so on.

So I strongly suggest you to keep working on your OOP skills and if you think you're ready to get started with the MFC's, just do it!

A word of advice if you're planning to get started with MFC: DO NOT USE THE WIZARDS. Wizard-generated code may be a little overwhelming and it may add a lot of confussion to your first MFC experiments.

But said that, go ahead and get your hands dirty with MFC! It is one of the greatest leap a C++ programmer can take, but it's worth the try!

[Lindley]

One of the mistakes that C programmers often make is thinking of C++ as "C with classes". If you're going to write C++, you should learn the C++ way of doing things, not just patch some additional syntax on top of your C habits. It's a somewhat different approach to coding, relying more on objects which clean up after themselves and less on keeping track of every little detail yourself. Efficiency is more a matter of proper algorithm and container choice and less a matter of counting cycles.

[DanLeon]

Thank your for your replys ;-)

One of the mistakes that C programmers often make is thinking of C++ as "C with classes".

Its interesting that you mentioned that because this is how i was seeing it. I have to admit that i do find it hard to understand C++ when looking at source code, i now realised that it is actually very different. I have no idea about using classes and the whole OOP approach.

If possible can you point me in the right direction on the best way to learn and understand classes, and inheritance, polymorphism and encapsulation ?

[Skizmo]

I have to admit that i do find it hard to understand C++ when looking at source code, i now realised that it is actually very different. I have no idea about using classes and the whole OOP approach.

Just start coding... after a while it comes naturally.

[Amleto]

Just start coding... after a while it comes naturally.

having been at the wrong end of some 'experienced' developer's code, I can assure you that it doesn't come naturally to all.

[Paul McKenzie]

If possible can you point me in the right direction on the best way to learn and understand classes, and inheritance, polymorphism and encapsulation ?

www.parashift.com
www.cplusplus.com

Books:
"Accelerated C++" by Koenig & Moo.

The above book is for persons who already know how to program in one language, and are transitioning to C++. It teaches you how to write robust, bug free (if not relatively bug free) C++ programs using the facilities the C++ library provides, all in the shortest period of time. There isn't any time wasted on writing your own "linked lists" "dynamic arrays", etc. or fumbling around using char* and dynamic memory for string data, unlike 'C' code and books that teach you 'C' programming.

Basically, C++ programming is about how best to take existing standard components that are bug-free, well known to C++ programmers, and putting them together to make a program. The logic and smarts are still required to put together a program, but from a different perspective than for 'C' programming. You aren't focused on hoping your char array has enough room for a strcpy(), or that your linked list cleans up memory correctly, or any of those things. You know these all work correctly in C++, you're now focused on the task at hand, and that is what goal your program is supposed to solve.

A lot of 'C'-centric programmers seem to think that programming this way makes you a "dumb" programmer who will labor trying to write or cannot write "low-level" code. I can tell you that I have never met such a programmer who knows how to program in the C++ style (using algorithms, the C++ library, classes, knows exactly what they're doing at all times), and not know how to write mid to low-level code (and I've been in this business a very long time).

Regards,

Paul McKenzie

[Dawoodoz]

C++ with MFC is dangerous if you don't know exactly what you are doing at assembler level. It sounds like C# would be better for you. I usually write faster algorithms in a safe language like Java or Visual Basic because I have to simplify the low code just to make it safe. The most fast and dangerous thing in C/C++ is to use strings as reference types and how often do you use string methods in realtime?

[Amleto]

C++ with MFC is dangerous if you don't know exactly what you are doing at assembler level.

poppycock.

[Dawoodoz]

poppycock.

What do you mean?

[Paul McKenzie]

What do you mean?

You don't need to know assembly language to use a GUI framework. If you did, then that defeats the purpose of the framework.

Maybe for debugging some very esoteric errors, assembly is a good thing, but by no means is it necessary to know it to use a framework.

Regards,

Paul McKenzie

[Dawoodoz]

You don't need to know assembly language to use a GUI framework. If you did, then that defeats the purpose of the framework.

Maybe for debugging some very esoteric errors, assembly is a good thing, but by no means is it necessary to know it to use a framework.

Regards,

Paul McKenzie

If you don't know how assembler level works when using unmanaged C++, you might use a temporary pointer on the stack as a value, get odd race conditions and loose more performance than you gained from using C++ by preventing the compiler from optimizing. I haven't heard of any C++ programmer that never write bugs and when they do, the bugs causes other applications to crash.

[OReubens]

While having a knowledge of assembler for a particular machine has it's advantages. It in no way is necessary to code in C++ or use MFC.

If you say you do, then that is indeed just "poppycock".


The advantage of a language like C++ is that it allows you to write efficient programs by allowing you to use more complex datastructures and algorithms without the amount of effort you would have to do to do the same in assembler.
Performance gains are very rarely in the raw translation from C/C++ to assembler, most of the performance issues are caused by using inappropriate algorithms and datastructures.

I'm finding it particularly strange that you seem to be advocating to use Assembler, and then go on that you write

I usually write faster algorithms in a safe language like Java or Visual Basic because I have to simplify the low code just to make it safe.

JAVA ? Visual Basic ?
You can't get much more distant from "assembler" than languages that work on a VM.

[laserlight]

If you don't know how assembler level works when using unmanaged C++, you might use a temporary pointer on the stack as a value, get odd race conditions and loose more performance than you gained from using C++ by preventing the compiler from optimizing.

I suggest that you read Accelerated C++ by Koenig and Moo (Paul McKenzie mentioned it in post #7) to understand one method to teach unmanaged C++ without teaching assembly language or requiring such knowledge as a prerequisite, while avoiding the kind of pitfalls that you have in mind.

[Alex F]

Moving from C directly to MFC is not a good idea. It is better to start learning C++ writing good old console applications.
Since you mentioned Unix, maybe MFC is not the best choice, if you want to write portable code. wxWidgets and Qt allow to write portable code. Anyway, all these frameworks require good C++ knowledge.
Finally, about suggestion to avoid MFC Wizard. I disagree with this. Most modern frameworks, including UI, database etc., contain Wizards which generate a lot of standard code. The best way, IMHO, is to use Wizard, even if you don't understand Wizard-generated code completely. Old-style "make all yourself" approach make slow down your learning process, talking about high-level programming frameworks.