Archived

This topic is now archived and is closed to further replies.

vbisme

A different use of header files

Recommended Posts

Here is how I use my headers and to make libraries. Is it efficient? Let''s say I have only one .cpp file called "main.cpp" where the main loop is useds. Then I have: lib.h, lib2.h, lib3.h, and so on. In the libs: //lib.h: #include "lib2.h" #include "lib3.h" #ifndef _lib.h_ #define _lib.h_ //functions //classes //functions and classes from the other libs #endif //lib2.h #include "lib.h" #include "lib3.h" #ifndef _lib.h_ #define _lib.h_ //functions //classes //functions and classes from the other libs #endif //lib3.h #include "lib2.h" #include "lib.h" #ifndef _lib.h_ #define _lib.h_ //functions //classes //functions and classes from the other libs #endif /////////main.cpp #include "lib.h" #include "lib2.h" #include "lib3.h" //use of the libs There is no corresponding .cpp file for the lib header files. If the header files contain classes, the definition is within it. Is this an efficient way of code reuse and such?

Share this post


Link to post
Share on other sites
It''s silly. All your headers get included by _one_ source file; in that case you could just put them in one header file. Furthermore, you still have the potential for infinitely recursive inclusion (you include some files before the include protection).

Use forward declarations instead. I suppose that''s why you''re bothering to "inter-include" the headers anyway.

// struct A is declared in libA.h and contains a pointer to B
// struct B is declared in libB.h and contains a pointer to A
//
// libA.h
#ifndef _LIB_A_H
#define _LIB_A_H
struct B; // forward declaration
struct A
{
// other members
B *pBPtr;
};
//
// libB.h
#ifndef _LIB_B_H
#define _LIB_B_H
struct A; // forward declaration
struct B
{
// other members
A *pAPtr;
};
//
// main.cpp
#include "libA.h"
#include "libB.h"

int main(int argc, char *argv[])
{
A *my_a = new A;
B *my_b = new B;
my_a->pBPtr = my_b; // why you would do this in real life is beyond me, but it''s an example
my_b->pAPtr = my_a;
//
// deallocation:
my_a->*pBtr->pAPtr = NULL;
my_a->pBPtr = NULL;
delete my_a;
delete my_b;
return 0;
}




I wanna work for Microsoft!

Share this post


Link to post
Share on other sites
quote:
Original post by vbisme
How would you do that with class instead of struct?


In exactly the same way. In C++ a class and a struct is the same thing with the small difference that the default access-modifier for structs is ''public'', but it is ''private'' for classes.

Share this post


Link to post
Share on other sites
Well, I not only need to make instances of a certain class in another class, but use it''s functions as well. If I just declare
class A;
class B
{
A *myA;
};
B::B()
{
myA->SomeFunction();
}

It will not work!

Share this post


Link to post
Share on other sites
quote:
Original post by vbisme
Well, I not only need to make instances of a certain class in another class, but use it''s functions as well.

That, dear fellow, is why you seperate declarations (contained in header files) from implementations (contained in source files). In the case you cite above, use a forward declaration of class A in the header file of B. Now create a source file (say, libB.cpp) for B and include both the header files of A and B in it. Presto! Code works.



I wanna work for Microsoft!

Share this post


Link to post
Share on other sites
If however:

#ifndef _A.h_
#define _A.h_
#include "B.h"

//declarations for class A

//codes for class A
#endif

#ifndef _B.h_
#define _B.h_
#include "A.h"

//declarations for class B

//codes for class B
#endif

When reuse, don''t have to carry around twice as many different files.

Share this post


Link to post
Share on other sites
Is it really such a nuisance to have a few files more?

Separating implementations cut down on the compile time. Not separating them is very likely to introduce code bloat and/or multiple definitions of the same method (leading to linker errors, etc.) if you ever have more than one source-file.

In short: Keep the declaration and implementation of your classes separate. It''s a lot cleaner. (Templates can be regarded an exception to this rule, since few compilers currently support separate declarations and definitions of templates properly.)

Share this post


Link to post
Share on other sites