Am I ready for C++ and MFC ?

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 ?

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!

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.

Thank your for your replys ;-)

Quote:

---

Originally Posted by Lindley

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 ?

Quote:

---

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.

Quote:

---

Originally Posted by Skizmo

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.

Quote:

---

Originally Posted by DanLeon

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

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?

Quote:

---

Originally Posted by Dawoodoz

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

---

poppycock.

Quote:

---

Originally Posted by Amleto

poppycock.

---

What do you mean? :D

Quote:

---

Originally Posted by Dawoodoz

What do you mean? :D

---

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

Quote:

---

Originally Posted by Paul McKenzie

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.

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

Quote:

---

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.

Quote:

---

Originally Posted by Dawoodoz

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.

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.

Quote:

---

Originally Posted by OReubens

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

---

I never said that people should use assembler. It is better to learn OOP on a virtual machine that allow mistakes before going for performance in C++.

Quote:

---

Originally Posted by Dawoodoz

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.

---

But you don't need to know assembly language to understand or debug those problems. I have to go with the poppycock crowd on this one.

Quote:

---

Originally Posted by Dawoodoz

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,

---

But you don't need assembly to know that -- you need knowledge of what C++ considers "undefined behaviour". Either you know your C++ or you don't.

I would even say that using assembly language to figure out what is legal or illegal in C++ is not recommended. What if your program works, even though you are using a pointer to a local variable? How would you know that it is illegal C++ if the assembly code shows that it works?

If anyone came to me and said "it's legal to do this in C++ because the assembly code shows this...", I don't listen any further.

Regards,

Paul McKenzie

Valid C++ works well in theory but when you do something wrong, that theory means nothing.

Quote:

---

Originally Posted by Dawoodoz

Valid C++ works well in theory but when you do something wrong, that theory means nothing.

---

And your point is...?

Quote:

---

Originally Posted by Dawoodoz

Valid C++ works well in theory but when you do something wrong, that theory means nothing.

---

I don't get it either. :confused:

Thank you all for your replies ;-)

Quote:

---

Originally Posted by Paul McKenzie

"Accelerated C++" by Koenig & Moo.

---

Thank you for this, I will look into it.

I just wanted to ask, is it a bad thing to mix C with C++ ?

The reason why I have asked this is because I have read some source code found on the net which uses printf()'s NOT the (std::printf() <cstdio>) as suppose to cout. I know this may just come down to personal preference when it comes to I/O but I was more surprised to see standard C string functions like strlen() and strcpy() instead of string::length, and string::copy in classes.

Many Thanks!

-Dan

I don't know much about C/C++ my background is C# (started to learn since last summer)
Bad or good is opinions and jobs of the language Standards members and language developers
Being just a normal software developer really doesnt relate much to it because developers must answer "will my joint to make this product benefits better my income ? Can I do it ? Will the final product have no bugs ?"
The last question will be left for QC testing group, rarely do I find bugged products returned if their coders have some actual coding experience, they tend to test while coding (at the same time).

Quote:

---

Originally Posted by somedaysomewhere

I don't know much about C/C++ my background is C# (started to learn since last summer)
Bad or good is opinions and jobs of the language Standards members and language developers
Being just a normal software developer really doesnt relate much to it because developers must answer "will my joint to make this product benefits better my income ? Can I do it ? Will the final product have no bugs ?"
The last question will be left for QC testing group, rarely do I find bugged products returned if their coders have some actual coding experience, they tend to test while coding (at the same time).

---

:confused:

The only point I can understand is your last one, and I don't agree with it. The only programs that won't have bugs in them are very small ones. When you get into large, complex systems, there are going to be side effects that programmers can't foresee, and full regression testing is the only way to find them.

Quote:

---

Originally Posted by DanLeon

I was more surprised to see standard C string functions like strlen() and strcpy() instead of string::length, and string::copy in classes.

---

There are some possible reasons:

1) The author of the code didn't know C++ well enough at the time he/she wrote the code, so they fell back to what was comfortable to them -- using 'C' functions.

2) The code was written a long time ago (before 1998 when C++ became standardized), therefore usage of 'C' functions instead of a non-standard string class.

3) The code was written by a programming student, where the teacher has given them the (IMO) ridiculous constraint that they cannot use std::string. That occurs often here.

4) You are looking at the internals of a string or string-like class, so usage of the 'C' library may show up to do the low-level copying.

5) The author is given a char buffer from potentially another language passed as a parameter, and their function has to fill this buffer with the string data on return. Exported functions from DLL's that fill in a buffer with info usually fall into this category.

6) The author is paranoid or misinformed/illinformed and believes that 'C' functions are safer and faster than C++ classes. Usually the coder is a veteran 'C' programmer who doesn't "trust" C++.

Take your pick. There are probably other reasons, but these are the reasons I've encountered (whether on the job, on programming forums, etc.).

BTW, "Accelerated C++" makes no mention of strcpy(), strcat() or any of those 'C' string functions -- you go straight to the std::string functions for string manipulation. The reason is that these C functions inherently put holes in the security of your program by opening up for buffer overruns.

Unless the coder has written wrappers around these functions to ensure that copying beyond the bounds of the destination buffer cannot occur, the program is a security risk in the worst case scenario, or will run but can potentially cause a memory overwrite in the best case.

As far as mixing C++ with C, the issue is that you should strive to not mix 'C' style programming with C++. The reason is that using 'C' style inherently makes you use 'C' constructs on things that are not 'C' compatible. For example, using memset(), memcpy(), or other 'C' functions on non-POD types is one such error.

If you are to use C style programming in C++, you better know exactly what you're doing and why you're doing it. This means you need to have a solid grounding in C++, know the difference between POD and non-POD types, know that using 'C' doesn't necessarily mean faster code, etc.

In my experience, most of the time I've seen 'C' style used in C++ programs for the simple reason that the coder just didn't know any better, and just fell back to what they knew or what they were comfortable with (which is why I put that first on the list).

Regards,

Paul McKenzie

It is absolutely OK to use CRT functions like printf or strlen in C++.

Quote:

---

Originally Posted by Alex F

It is absolutely OK to use CRT functions like printf or strlen in C++.

---

Right.
Even C++ standard has a list of headers for using Standard C Library: <cstdio>, <cstdlib>, <cstring>, and so on.

Hi Paul,
what you mean by POD and non-POD types ?

Quote:

---

Originally Posted by vcdebugger

Hi Paul,
what you mean by POD and non-POD types ?

---

POD stands for Plain Old Data. These types are compatible with 'C' types.

Non-POD types are types that are C++ only. These types include structs/classes that have virtual functions, user-defined constructors and destructors, types derived from other classes/structs, etc. Doing 'C' things on these types usually results in undefined behaviour.

Regards,

Paul McKenzie

thanks Paul for the info.

Quote:

---

Originally Posted by Paul McKenzie

Doing 'C' things on these types usually results in undefined behaviour.

---

One possible next question may be:
"Hi Paul,
what you mean by undefined behaviour ?" :D

You never say what you plan to do with programming once you learn C or C++.

I used to program in C++, including managed C++, C, VisualBasic, Pascal, etc. Since C# came out I haven't bothered with C++. It's much easier to write Windows program in C# than in C++. Also, managed C++ is a very wierd form of C++, not at all standard.

IMO, the main reasons for using C++ are:
1. To support legacy programs.
2. To write low level code, like device drivers
and 3. To write code that is portable to other operating systems

4. when you need to control memory management.
5. when other dependencies are not acceptable e.g. .net

While it certainly is possible to have sources in a variety of languages and then link these into a single binary, personal experience in this matter would make me recommend avoiding this. It invariably causes a number of issues, especially if not everyone on the team is equally proficient in each of the languages.

If you have a project where several parts HAVE to be made in different languages, I would recommend making each of the languages build their own binary (DLL's) and use the defined exports of those. While it takes some more planning and setting up different projects at the start, it usually is much more convenient down the road.

As to why c++

6. When performance matters
7. When you have developed good libraries and follow some basic rules, C++ is just as easy to use as C# to write (windows) programs. The rules aren't necessarily a limitation. You can write "bad" programs in C# just as well.
8. When timely resource recuperation matters. (garbage collection is notoriously bad in this respect).
... to be continued ...

Certainly those other items, 4 - 8, may justify using C++ instead of C#, but for most programs those considerations don't usually come into play. By the way, I'm really talking about writing Windows programs. For other OS's there may be other considerations.

I'm not sure that item 7, saying C++ is just as easy to use as C#, is true. Not having to worry about pointers, or that wierd caret notation, or making sure that you are really writing managed code, makes C# a lot easier to write.

Also, DanLeon /C++ for. Since he is just learning, if he wants to write Windows programs, C# is really the way to go.

Quote:

---

Originally Posted by cgantz2000

Certainly those other items, 4 - 8, may justify using C++ instead of C#, but for most programs those considerations don't usually come into play. By the way, I'm really talking about writing Windows programs. For other OS's there may be other considerations.

I'm not sure that item 7, saying C++ is just as easy to use as C#, is true. Not having to worry about pointers, or that wierd caret notation, or making sure that you are really writing managed code, makes C# a lot easier to write.

Also, DanLeon /C++ for. Since he is just learning, if he wants to write Windows programs, C# is really the way to go.

---

they were reasons to use c++. The caret syntax is "Managed c++" and therefore not c++. Pointers are a non-issue with smart pointers, namely boost or maybe Qt, not std::auto_ptr. No one was talking about reasons to use managed, or suggesting that someone starting out should look into managed c++.