Help Me Understand C++ Header files and Classes

OK, So I am trying to transition from intermediate Delphi to C++ Object Oriented programing. I have read Ivar Horton's book on visual C++ 2010. I can pull off the simple console applications no problem. I get the language itself (kinda). Where I am struggling is with headers and classes.

I also understand what header files 开发者_Go百科and classes do in general. What I am not getting is the implementation when do I use a header or a class? Do I need to create classes for everything I do? Do my actual work functions need to be in header files or in CPP files? I'm lost on the proper uses of these and could use some real world guidance from more experienced programmers.

I am trying to transition to windows applications using the MFC if that is helpful.

I also understand what header files and classes do in general. What I am not getting is the implementation when do I use a header or a class? Do I need to create classes for everything I do? Do my actual work functions need to be in header files or in CPP files? I'm lost on the proper uses of these and could use some real world guidance from more experienced programmers.

Re-wind a few years and I'd have had the same question - it isn't something that is covered very well I don't think. So let's break down that part which I see as the meat of your problem.

Do I need to create classes for everything I do?

That's subjective, but I'd say no. You need to create a class for things you want to model, where it makes sense to do so. An example might be an item of data that is more complicated than C's types like int and char. You should also use the String class and STL's containers (look at vector). In short, what this means is you will probably be using a class for most things you do, but that doesn't mean to say every last little part of your code must somehow fall into a class, somewhere.

I also understand what header files and classes do in general.

Let me just repeat what you get then. As you are probably aware, C and consequently C++ requires prototype definitions for functions that do not precede it in the compilation unit (complete source code after all the headers replace their includes). As such:

#include <iostream>
using namespace std;

int testadd()
{
    int a = 4; int b = 2; int c = add(a, b);
    return c;
}

int add(int x, int y)
{
    return x + y;
}

int main(int argc, char** argv)
{
    cout << "result is: " << c << endl;
    return 0;
}

(Contrived example) won't work, because testadd can't find add but main can find add.

So your program ideally ought to begin with a list of all the functions, classes et al you want to use. Somebody decided it would be a good idea if these were in a separate file from the implementation as it makes things a lot easier to read and saves programmers using your work (in the library scenario) from re-writing prototypes to your functions. Makes using any other library a lot easier.

So, when you implement your classes, you have a choice:

1. Declare the classes in prototype form (functions end as prototypes) and implement them in a cpp unit.
2. Implement the whole lot in a header file.

Which you do is honestly up to you. I stick to 1, because I think it's nicer, but nobody says you must and I have seen both techniques used.

Incidentally, just worth mentioning, if you choose 1, let's say you have main.cpp, myclass.h, myclass.cpp and you call myclass methods implemented in myclass.cpp from main.cpp, what happens in compilation is that these two units (*.cpp) are compiled to machine code form (main.obj and myclass.obj in the case of vc). A linker is then responsible for bringing these two objects into an exe, ensuring all the symbols functions) called in each compilation unit can be found in one of the referenced other objects or libraries. If that happens, it puts together an exe. If not, you get an error. That's the other consequence (link errors) which provoke such questions in learning users.

Headers in C++ are like the interface in Delphi units; they define what other compilation units are allowed to know about (via prototypes and declarations), and what the associated compilation unit is allowed to know about other compilation units (via external declarations). They aren't strictly required in single-compilation-unit programs, but they can help you think about a clear separation of responsibilities.

Classes in C++ are much the same as classes in Delphi; you use them when appropriate for the task.

I also understand what header files and classes do in general.

No, sorry. I'm afraid you don't. I can tell just by the terms you're using in that statement.

The word "header" and "class" are not only NOT exclusive, or related...they're not even at the same level.

A "class" is a C++ language construct.

A "header" is a file on the filesystem that contains C++ code.

What I think you mean by "class" in the context you're speaking is correctly known as "translation unit", a .cpp file. The problem here is that classes do not have any sort of 1:1 or even 1:many relation with translation units. Bits of class code can appear in any number of .cpp files and .cpp files can contain bits of any number of classes and other things.

In fact, if we were to continue with incorrect terms, and skip some inconvenient facts, it would be headers that should be known as "class" files since that's where class definitions usually appear (that part that says class {...};). Even so though, we have to leave this universe for another because you're entirely free to define classes in translation units as well.

The difference between header and translation unit (or "source file" if you want) is that the code within headers is not compiled as a header element, it's stuck, entirely, in the "source file" you include it in. In other words, headers are never compiled, they're preprocessed.

The things you put in headers are those things that you WANT copy/pasted everywhere that you include them. Class definitions or declarations are but two of those things. You may wish to include inline function code (code you hope the compiler will paste where its used instead of jumped to--though this isn't the exact story either). Templates are other things good to put into headers because they have to exist, completely, wherever you try to instantiate them (so they have to be copy/pasted everywhere).

The things you put into "source files" are those things that you only want one of, either because you want just local access or because more than one example of that thing would violate the language (multiple definitions of the non-inlined, global f() function for instance).

So, happy to help and happy to confuse at the same time. I know you STILL don't understand it but at least you are more aware of that fact now.

Header files are not NECESSARY. You could theoretically build your entire application with only implementation files. The point of header files is to separate definition from implementation. They are a way to make linking and compiling easier/faster.

And no, you don't need to create classes for everything. Global functions are perfectly legal in C++.

Ouch.. This is kind of huge topic. You're asking about explaining the whole concept of OOP. There is a lot of stuff in the web about it. First I foun:
OOP Concept in Java - this one is in Java, but the concept is the same. And what's more in C++ you have this stupid headers. Header is basicly information about what the class contains. So header itself have no crucial code, only the "introduction". During compilation the code is taken from classes. I hope it helped.

Object Oriented Programming with C++ by David Parsons is really easy to follow with good examples if you fancy another book to help you on your way :)