Making Classes header files.

Is it good practice to make a class in a different program then save it as a .h or .cpp and then use it in a header file for another program. I am not sure about this. In Sams book(24 hours) he says that it is good practice and I can see why. It would make the actuall code a lot shorter. But is this customary?

Personally, I use that method often, and I like it. Mostly, I create a wrapper class for a control (Win32 API), with the declarations in a .h file, and the definitions in a .cpp file. That way, you just include the header file in each of your other source files, like this:

Code:

---

//clsTree.h
class clsTree
{
public:
HWND hTree;
void DoStuff();
};

---

Code:

---

//clsTree.cpp
#include "clsTree.h"
void clsTree::DoStuff()
{
//code
}

---

Code:

---

//other source file
#include "clsTree.h"
fooblah

---

Or, you could create a dynamic link library. More complicated though.

Actually in the sources you should include the .cpp file. Otherwise you don't include the definitions of the functions and the coputer wouldn't know what to do.

Quote:

---

Originally posted by -=SoKrA=-
Actually in the sources you should include the .cpp file. Otherwise you don't include the definitions of the functions and the coputer wouldn't know what to do.

---

Nope, you include the h file so the "names" (classes, defs, types...) declared in there become valid. Then you add the c(**) files to make's list of stuff that needs to be compiled.

>>Nope, you include the h file so the "names"
>>(classes, defs, types...) declared in there become valid.
Are you talking about the definition file or the sources where the program is?
What I meant was that when bennyandthejets put in the other sources the .h file, the declarations wouldn't get included. That way, since the .cpp file already includes the definitions file, you should include the .cpp file.

It looks to me that you're talking about the program make. I'm talking about only using the compiler.

Quote:

---

Originally posted by -=SoKrA=-
>>Nope, you include the h file so the "names"
>>(classes, defs, types...) declared in there become valid.
Are you talking about the definition file or the sources where the program is?
What I meant was that when bennyandthejets put in the other sources the .h file, the declarations wouldn't get included. That way, since the .cpp file already includes the definitions file, you should include the .cpp file.

It looks to me that you're talking about the program make. I'm talking about only using the compiler.

---

Well, I think we were talking about "good practice". If you ask me, it's good practice not to use #include on non header files, but thats of course just me.
However, you are right, the cpp files won't get included if you only #include the .h file. Thats why I said it would be a good idea to add them (the .cpp's) to the list of stuff that needs to be compiled (and linked).

The reason is, that once you have your cpp's compiled to a nice handy .lib, your code that uses these cpps won't compile anymore if you used include on cpps.

You do NOT want to #include a .cpp file. The compiler doesn't need to have the function definitions, only the declarations. So you should #include the .h file and compile, then compile the .cpp file, and link the two together (along with any other .cpp files).

You see, Sokra ? Whatever Cat says is true :)

Well, I can see you're all aginst me :(
I'm in a slightly different mindset. I've always been using command line and, being very lazy, just included everything into a main file and just told the compiler to compile and link that.
When I made the first post I wasn't thinking that the deffinitions file would also get compiled and that's why I said that the .cpp files would need to get included.
I'll try to think about that next time :)

So, at the end of all this, was I right? I mean, that method always works for me.

Quote:

---

Is it good practice to make a class in a different program then save it as a .h or .cpp and then use it in a header file for another program

---

Yes, reusing classes is a good practice. That's why it's good to keep reusability in mind when you are designing a class. Reusable classes can prove to be huge time savers.

Quote:

---

So, at the end of all this, was I right? I mean, that method always works for me.

---

Yes, as long as the object code defining the class's members is linked against the other program code, as Cat said.

There are very good reasons for only including header files (with the interface only). Whenever you modify a file, you will have to recompile every other file that depends upon that one. Often, your class interfaces will be well thought out, and so the interface (header file) is fairly unlikely to change. The implementation, however, is quite likely to change as algorithms are modified, or bugs are fixed. Now everything calling the class needs only to know how to call it (the declarations which have not changed), so changing the implementation will not force a recompile of your entire project. Rebuilding a single object file and then relinking your program (for very large programs) can significantly increase the speed of your rebuilds.

Thanks for the info, I am just covering this in Deitel & Deitel.

In general, the best approach is always "include as little as you can get away with". If you don't need a definition, use only a declaration. And you'd be surprised at how rarely you need a definition. For example, if you had this in a header file:

Code:

---

class Teenager: public Person{
public:
  Teenager(Mother &m, Father &f);
 
  Mother GetMother();
  Father GetFather();
 
  void IgnoreParents();
  void BeMoody();

private:
  Mother & m_mom;
  Father * m_dad;
};

---

In the above class definition, ONLY "Person" must be defined. Mother and Father must only be declared. So you can get away with merely this in that header:

Code:

---

#include "Person.h" // Can't get around this include

// But we don't need to include "Mother.h" or "Father.h"
// This works equally well:
class Mother;
class Father;

---