headers simplified...please

I guess this is a multi-part question. I am taking a crack at creating and using header files for custom classes. What I would like to be able to do is just call my custom header file for my custom classes then be able to use my custom classes.... simple right? Here are the problems I am running into.

First is how do I call my custom header file in the #include command? The header file sits in a local directory off of my home directory. Do I need to put my header file in a special directory, e.g. /usr/include/, or can I call it from the path where its located?

Second part. From what I understand the header file only has the declaration and the implementation goes somewhere else. So I did that. But now what? One book I've head has the implementation file calling the header. Another website I went to has the header file calling the implementation file...though it stated thats not the best way of doing it. If I hope on just calling the header file to utilize my customer classes, then I would assume that the header file would have to call the implementation file. But then where would I put the implementation file (same question as above but for the implementation file).

Any help would be greatly appreciated. Thanks!!

You can put your header wherever you want. You just need to tell the compiler where it is. This is done by adding the path to your visual studio project settings, or passing the -I option to gcc.

Your second question is kind of confusing. You don't "call" a file in c++. Just include the header file, and then use the class that is defined in it.

bithub,

Thank you for your quick response. I realize the word "call" has specific meanings so I should of used a different word. Lets say I have my_class.h and my_class.cpp files (where .h is the deceleration and .cpp is my implementation file), if I include just the header file in my_program.cpp file, must the header file include the implementation file? If so, I guess the implementation file would have to sit in the same directory as the header file?

If this is the case, then why would my c++ book state the opposite?

thanks again!

The include statement should be constructed with a path relative to the including file. That is, if your header file is in the same folder as the file including it, the statement is as simple as:

#include "headerfile"

If the header file is in different folder, you should direct a relative path to it:

#include "relative_path/headerfile"

Now... That is enough. But your compiler helps you simplify this. You have an option to add include paths to it. If you use that option to add a full path to your header(s) location, you can then revert to:

#include "headerfile"

no matter where your source files are located.

The implementation needs to see the declaration (else how it will know what makes up your class?) so your .cpp file needs to include your .h file. They usually sit in the same directory, but they don't have to, as long as you specify the path to the .h file in your #include statement, or putting that directory in the search path that your compiler looks at, as bithub suggested.

Your my_class.cpp file should just have the functions listed in the my_class.h file (and maybe some extra helper functions that the outside world shouldn't see). Elsewhere, you're going to have the actual main() function that runs in some other piece of code, like my_main.cpp. This also needs the headers, so you #include that .h file there as well, so that it knows what's inside your class too. Each .cpp file can then compile (it has the information it needs), but for an executable to be created, the two files then need to be linked together (this happens for you, often, either in MSVC by putting everything into the same project, or in g++ by specifying all the .cpp files on the command line/in the makefile, or something similar).

And in order to better understand this, you can also search google for "c++ one definition rule".

tabstop,

I follow. You are suggesting I link my_class.cpp with my_main.cpp at compile time. While this is fine its not really what I wanted. For example when I use <vector>, I do not have to compile vector_implementation.cpp when I compile my_main.cpp. All I do is include <vector> and then I can use all the vector classes. Thats what I am trying to duplicate.

Quote:

---

Originally Posted by jmartrican

tabstop,

I follow. You are suggesting I link my_class.cpp with my_main.cpp at compile time.

---

Except I'm not. Linking is always the last step, after preprocessing, compiling, and assembling.

Quote:

---

Originally Posted by jmartrican

For example when I use <vector>, I do not have to compile vector_implementation.cpp when I compile my_main.cpp. All I do is include <vector> and then I can use all the vector classes. Thats what I am trying to duplicate.

---

That's true. And, funnily enough, that's what I'm suggesting you do. You're going to have to compile your my_class.cpp file once, at least, just as they had to compile their code before putting it in. But once it is, it can be linked against as many my_main.cpp files as you can shake a stick at without recompiling it. (It will create a object file, .obj or .o, while the libraries are generally .lib or .a, but the idea is the same.)

tabstop,

When I use vectors I do not have to deal with precompiled objects in my makefiles or on the command line. All I do is #include <vector>. All I want to do is #include "my_class.h" in my_main.cpp and then use my_class objects. Nothing more nothing less.

So I went and wrote my_class.h, my_class.cpp, and my_main.cpp. The files are sitting in my home directory. I know I can add #include "my_class.cpp" at the bottom of my_class.h, but this was not recommended in a C++ book of mine.

thanks

Quote:

---

Originally Posted by jmartrican

tabstop,

When I use vectors I do not have to deal with precompiled objects in my makefiles or on the command line. All I do is #include <vector>. All I want to do is #include "my_class.h" in my_main.cpp and then use my_class objects. Nothing more nothing less.

thanks

---

The linker still needs to be told what library to link to; the fact that your compiler or IDE hides this from you doesn't mean it doesn't happen.

(In fact, just now I tried to run ld on a program's .o files without specifying any standard libraries; sure enough, malloc, and strlen, and sprintf, etc. were all undefined references. But if gcc is compiling and linking at the same time, it knows which libraries to bring in.)

What compiler are you using? If you're using an IDE, this is the sort of thing that projects and automatic makefile generation is for. This way the compiler will tell the linker the right thing as well. (And you'll still not have to re-compile the files you didn't change, etc.)

Quote:

---

Originally Posted by jmartrican

So I went and wrote my_class.h, my_class.cpp, and my_main.cpp. The files are sitting in my home directory. I know I can add #include "my_class.cpp" at the bottom of my_class.h, but this was not recommended in a C++ book of mine.

---

You include my_class.h in my_class.cpp. If you then need to use my_class objects, you include my_class.h on every other cpp file that uses them. On your case my_main.cpp. You don't include cpp files, ever.

When you compile, you compile all cpp files. If you don't change my_class.cpp code or delete the object file resulting from its compilation, that my_class.cpp won't be compiled again by your IDE, next time you build your application.

When you link, you link all object files.

I'm using g++.

I took a peek at the vector file and it in fact is nothing more than a bunch of #include "somefile.h".... which lead to more files that eventually defined the vector class (non-compiled code). So I guess regardless of what my book states I can include "my_class.cpp" in my_class.h. This way I just include my_class.h in my_main.cpp without having to worry about libraries and projects.

thanks

As you wish.

Mario,

That is what I am trying to avoid.

Ultimately I am going to create a package that will dump my_class.h and my_class.cpp in the same directory. I will then just do g++ my_main.cpp (which has - include "my_class.h" - in it) and everything will be fine. No complicated pre-compiling, objects, and/or libraries. Just simple includes. Still can't figure out why my book states that implementation files should not be included in header files... though vector does just that from what I've seen.

Quote:

---

Originally Posted by jmartrican

Mario,

That is what I am trying to avoid.

Ultimately I am going to create a package that will dump my_class.h and my_class.cpp in the same directory. I will then just do g++ my_main.cpp (which has - include "my_class.h" - in it) and everything will be fine. No complicated pre-compiling, objects, and/or libraries. Just simple includes. Still can't figure out why my book states that implementation files should not be included in header files... though vector does just that from what I've seen.

---

I will let the experts speak definitively, but I think that's more a relic of templating than anything else (IOW, you'll have to compile vector yourself, since you're instantiating an instance of a template). I would be surprised if you found much source code following cmath, say, or ctime.

tabstop,

Thats a good point. I took a look at cmath and it leads to more include files. There was some implementation in the cmath file, actually a lot. I followed the included files which lead to more code and more included files. So how does this eventually lead to pre-compiled objects and libraries?

I have gcc 3.4.5 (at least here on this Windows machine), so maybe there's differences: in my cmath file, I have a lot of "code" that changes the name back to the old-style C names (so asin may go to asin, or asinf, or asinl -- actually with the _builtin__ prefix), but neither c++config.h, cmath.tcc, cpp_type_traits.h, or math.h had any source for any of those functions.

The compiled source for all of those is in libm.a in your lib subdirectory (and if you #include <cmath>, you need to compile with -lm at the end on *nix -- there's a reasonably well-known bug in gcc about that).

Here's the deal:
my_class.h contains the class definition, and does not under any circumstances include any .cpp file. C/C++ doesn't work that way.
my_class.cpp should include my_class.h.
Every other source file that uses my_class should include my_class.h.
No file should include my_class.cpp whatsoever.

You compile all source files.
You link all object files.
Or you just use a proper IDE that does all this for you.

You should never include a .cpp file because they contain function definitions and class implementations, so if you include the same .cpp file twice somewhere, you get linking errors.

The fact that you can include vector and just use it is because it's located in a library somewhere and you tell the linker to link against that library.

I suggest that you do not take <vector> as an example. The <vector> standard header is for the std::vector class template. The rules for templates can be a little different from normal (e.g., Elysia's dictum that one should "not under any circumstances include any .cpp file" does not necessarily apply as one may include the source file with a class template's implementation into its header file).