I have the following class that is in file called fooTest.cpp:
#include <iostream>
#include <string>
using namespace std;
class foo
{
private:
float price;
public:
foo():price(0){}
foo(float p)
{
price=p;
}
void print()
{
cout<<price;
}
};
and my main program is in another file called test.cpp
#include <iostream>
using namespace std;
int main(void)
{
foo p1;
p1.print();
system("PAUSE");
return 0;
}
The problem it does not recognize the object p1, why is that? I do not want to use a header in this program
sidenote: I am using Visual C++, and both files are in the same Source Files folder
Why do you think it should be a valid reference? Test.cpp knows nothing about the other cpp file at compile time. It is only when you link your object modules together, that references can be resolved. You need to use a header. That is a standard practice.
** The problem it does not recognize the object p1, why is that?* *
When you compile a source module, the only thing a compiler sees is what you give it in that module.
#include <iostream>
using namespace std;
int main(void)
{
foo p1;
p1.print();
system("PAUSE");
return 0;
}
Where do you see any definition of foo? You don't see it, and neither does the compiler. The compiler sees "foo p1;" and says to you "what is a foo?"
** sidenote: I am using Visual C++, and both files are in the same Source Files folder **
If you thought that the compiler will do a directory search for your other modules to figure out these unknown types, then you're mistaken. C++ doesn't work that way -- it compiles what it is given, therefore you must tell the compiler what a foo is before you can start to use it.
You can always include fooTest.cpp directly to your test.cpp, and compile directly with
gcc test.cpp
But then again, why would you not use header for that? And compile regularly like
gcc test.cpp fooTest.cpp
And, how do you expect it to compile correctly without any reference to fooTest.cpp
You can't use a class that hasn't been defined. One way or another, the compiler must see the definition of class foo while compiling test.cpp.
You can accomplish that by moving it into a header, or you can just copy and paste the class definition into test.cpp. But copying it is a bad idea, because then when you make changes to the class in the future, you have to make each change in both places. The class must always be defined the same way in all files where it's seen.
This is exactly what header files are for: making the same code in multiple source files without having to maintain multiple identical copies of the code.
You have to include the class declaration in each source file that references or defines an object based on that class. The standard way to do this is to place class declarations in a header file so that the declarations for a given named class are identical.
If you don't want to include the class declaration in a header file, then simply include the class declaration in each source file that references it. In your case, copy
class foo
{
/* the rest of your fooy guts */
};
into test.cpp.
Are you a Java programmer, by any chance? Java handles this in a more automatic fashion than C++, unfortunately.
Related
Below are two files, one contains the main functions and the other the h file
main
class issuesofRelevance{
public:
vector<string> issues;
int significance = 0; //initalize 0
int approach = 0; //initalize 0
issuesofRelevance() {
}
void setStance(vector<string> issues, int significance, int approach){
std::random_device random_device;
std::default_random_engine generator(random_device());
std::normal_distribution<double> distribution(0,1);
}
};
h file
class issuesofRelevance
{
public:
std::vector<std::string> issues;
int significance;
int approach;
issuesofRelevance(){}
public:
void setStance(std::vector<std::string> issues, int significance, int approach){}
};
When i attempt to compile these 2 files i get the error
error: redefinition of ‘class issuesofRelevance’
class issuesofRelevance{
Im unsure as to why this is occuring
Let's say the main function is in main.cpp and the class is in IssuesofRelevance.h. You didn't mention anything about if you included the .h file in your .cpp file. But I am assuming that you did. So I am assuming you wrote
#include "IssuesofRelevance.h"
At the top of the main.cpp function. Now, what #include directive does, it takes the content of the included file, and copy pastes it in to the main.cpp file. Now you see, you have a class declaration in IssuesofRelevance.h file which is copy pasted in the main.cpp. Also, you have the same declaration in main.cpp file. So the compiler is seeing that you are declaring two classes having same names. Which is not allowed.
So if the two classes are the same then cut the one in main.cpp to the IssuesofRelevance.h and just go with including the .h file in the main.cpp. Everything should be fine.
Though in this way it will work. But, you might want a separate .h file and .cpp file for your class. The .h file contains the declaration. Declaration means the class' member variable and method signatures. And .cpp file will contain the method bodies. I think you wrote the definition in main.cpp file. You can do the declaration in the following way.
issuesofRelevance.h
class issuesofRelevance
{
public:
std::vector<std::string> issues;
int significance;
int approach;
issuesofRelevance();
public:
void setStance(std::vector<std::string> issues, int significance, int approach);
};
issuesOfRelevance.cpp
#include "issuesofRelevance.h"
issuesofRelevance::issuesofRelevance(){
}
void issuesofRelevance :: setStance(std::vector<std::string> issues, int significance, int approach){
std::random_device random_device;
std::default_random_engine generator(random_device());
std::normal_distribution<double> distribution(0,1);
}
Put your class along with relevant code you desire in a header file (.h extension, and easily configurable in workspace by an editor such as Visual Studio), and call it as in when required, using #include"filename.h".
Note that header files are basically chunks of code copy-pasted into the source file and so if they include different definitions of the same function or say class for your case, it will result in ambiguity and throw an error - which is the situation in this scenario for your class issueofRelevance.
Corresponding compiling & linking errors:
If you write two same class definitions together in a file, then it will throw up an error due to the arising ambiguity which is detected by the compiler, since its only in a single file.
But when you place those two same definitions in different files and import them into your cpp file twice (or say you import them in another cpp file and build the solution like in visual studio) it will throw up a linker error as the linker is involved (multiple files - wherein the job of the linker is to link them into a combined executable) and it cannot select multiple definitions present in different files.
If your dealing with functions, then a solution to resolve that is to make the functions static, so that they are defined internally or only for the file they are being compiled against. This makes it possible to have multiple function definitions of the same function in different files with no linking error. Another option is to make it in-line.
You have defined the class issuesofRelevance twice so you got the compile error. You'd better define the class in one header file, and include it from other CPP file.
I have fixed your code and it's host online:
https://www.onlinegdb.com/ByuyF7BsL
It seems that you are new to c++, it's recommended to read some books like c++ primer
I am using GCC C++ 11 in CodeBlocks IDE. I have been trying to reuse classes that I wrote by putting them into a header file but it doesn't work. I have looked into many books but none has detailed information on making C++ code reusable.
There are a couple concepts that C++ uses that I think you're missing:
The difference between a declaration and a definition
#include statements
Linking against other libraries
In general, one reuses code in C++ by Declaring a function in a header file (.h), Defining it in a source file (.cpp). The header file ("foo.h") is then included in both the source file (foo.cpp) and any other file you want to use something declared in it using and preprocessor include directive #include "foo.h". Finally if the source file in which the functions declared in the header file are defined is not a part of the source for the library or executable that you're compiling, you will need to link against the library in which it was built.
Here's a simple example that assumes that you don't need to link against an external library and that all files are in the same directory:
foo.h:
The class Foo is declared along with a member function foobar and a private member variable barM. In this file we're telling the world that there is a class named Foo, it's constructor and destructor are public, it has a member function named fooBar that returns an integer and it also has a private member variable named barM.
class Foo
{
public:
Foo();
~Foo();
int fooBar();
private:
int barM;
};
foo.cpp
The individual member functions for our class Foo are defined, we implement the things we declared in the header file. Notice the include statement at the top
#include "foo.h"
Foo::Foo()
{
barM = 10;
}
Foo::~Foo()
{
}
int Foo::fooBar()
{
return barM;
}
main.cpp
We use our class in a different file, again the header file is included at the top.
#include <stdio.h>
#include "foo.h"
int main(int argc, char *argv[])
{
Foo flub;
std::cout << "flub's fooBar is: " << flub.fooBar() << std::endl();
return 0;
}
The expected output from this would be:
flub's fooBar is 10.
As a general note, I haven't compiled this code, but it should be enough to give you a basic example of the ideas of declarations, definitions, and include statements.
Seeing as you're coming from Java, I'm actually betting that you got all of that already, the hard part is actually using code from a different c++ library, which is akin to Java packages. Setting this up requires exporting the symbols you desired to use in a different library. The way to do this is compiler specific, but is generally accomplished by defining a Macro in a different header file and then using that macro in the declaration of the item you'd like to export. For gcc, see reference GNU Reference Manual.
To extend the above example you create another header file: fooLibExport.h
#if BUILDING_LIBFOO && HAVE_VISIBILITY
#define LIBFOO_DLL_EXPORTED __attribute__((__visibility__("default")))
#elif BUILDING_LIBFOO && defined _MSC_VER
#define LIBFOO_DLL_EXPORTED __declspec(dllexport)
#elif defined _MSC_VER
#define LIBFOO_DLL_EXPORTED __declspec(dllimport)
#else
#define LIBFOO_DLL_EXPORTED
#endif
foo.h would then be changed to:
#include "fooLibExport.h"
class LIBFOO_DLL_EXPORTED Foo
{
public:
Foo();
~Foo();
int fooBar();
private:
int barM;
};
Finally you'll need to link against the library that Foo was built into. Again this is compiler specific. At this point we're through the setting up of header files for exporting symbols from a C++ library so that functions defined in one library can be used in another. I'm going assume that you can follow the reference material for setting up the GCC compiler for the rest of the process. I've tried to bold the key words that should help refine your searches.
One final note about #include statements, the actual argument isn't just the filename, its the path, relative or absolute, to the file in question. So if the header file isn't in the same file as the file you're trying to include it in, you'll need to use the appropriate path to the file.
Code re-usability casts its net wide in C++ terminology. Please be specific what do you mean by it.C and C++ programming language features usually considered to be relevant to code reuse could be :-
functions, defined types, macros, composition, generics, overloaded functions and operators, and polymorphism.
EDITED IN RESPONSE TO COMMENT:-
Then you have to use header files for putting all declarations which you can use in any file just by including this.
Exactly as it states in the title, are header files that you use the #include for basically prewritten/pre coded classes filled with methods and variable that you can use once you include it into your script. Also how can one go about making one to the point where you can simply use header files that you created for your own benefit? A simple explanation will do.
Yes and no... it depends on many things.
An include directive -as for the standard C++ is- can be two things:
#inlclude "filename"
and
#include <header>
The first one literally means "keep the text contained in "filename" and paste it here.
So yes, the file can contain prewritten classes (but not necessaraily have to)
The second one means "let this source to use the facilities the standard defines in its <header> section. As per the standard definition goes, this is not necessarily meant to be a file, although all the implementation I'm today aware of in fact do: header is a file-name and <> and "" simply change the compiler search order.
You can -at this point- cut a "very long Cpp source" into smaller self-contained chunks and come to a cpp file that is nothing more than a sequence of #include and a main().
But that's not all.
A C++ program is not necessarily made by a single cpp file (a cpp file plus everything it includes either directly or indirectly is called "translation unit").
In fact compilation does not produce programs, but "object files" (the term is "ancient operating system terminology", and have nothing to do with object-oriented programming) that a "linker" puts together.
Because a C++ function calling another does not need -to be translated- to know how the other function is translated, but only how its parameters and return values have to be passed and taken, This makes you able to write the other function body in another independently compiled source and let the header to contain only its declaration (not definition).
For example you can have
// fooclass.h
#ifndef FOOCLASS_H
#define FOOCLASS_H
class foo
{
public:
void hello();
void bye();
};
#endif // FOOCLASS_H
,
// out.h
#ifndef OUT_H
#define OUT_H
#include <string>
void printout(const std::string& s);
#endif // OUT_H
,
//main.cpp
#include "fooclass.h"
int main()
{
foo afoo;
afoo.hello();
afoo.bye();
}
,
// fooclass.cpp
#include "fooclass.h"
#include "out.h"
void foo::hello()
{ printout("hello"); }
void foo::bye()
{ printout("bye"); }
,
// out.cpp
#include "out.h"
#include <iostream>
void printout(const std::string& s)
{ std::cout << "- " << s << " -" << std::endl; }
The entire program can be compiled (for example with GCC) as
g++ main.cpp fooclass.cpp out.cpp
or in separated step as
g++ -c main.cpp
g++ -c fooclass.cpp
g++ -c out.cpp
g++ main.o fooclass.o out.o
(if you use MS compilers, you'll most likely do
cl /c main.cpp
cl /c fooclass.cpp
cl /c out.cpp
link main.obj fooclass.obj out.obj
)
Only the last step makes up the program (note that main.cpp will never know about the printout function!). The previous three are required only for files that have been changed, thus on big projects can speed up compilation and distribute tasks to different teams. (there are utiities like make, that allow to automate this thing.
There is an exception to all that, that nowadays is more and more important: templates.
Since they are not implemented as "code to be translated" but as "code to be expanded", they can be translated only when what they have to expand is known.
template<class T>
T max(const T& a, const T& b)
{ return (a<b)? b: a; }
The meaning of (a<b) depends own what the type T actually is. And since it is know only when max is called, max can be expanded as max<int> or max<double> or max<string>
only when used.
For this reason, templates are not normally handled in independent translation units and library offering template classes or functions do that by just providing collection of headers containing all the code, with no source to compile separately.
are header files that you use the #include for basically prewritten/pre coded classes filled with methods and variable that you can use once you include it into your script?
That's the general concept. In C++, not everything needs to be in a class, so there can be non-member functions, types, preprocessor definitions, variables etc. too. Further, some headers declare variables, types and/or functions but do not define them - that means you can make limited use of them and generally have to present the matching implementation object at link or run-time.
Also how can one go about making one to the point where you can simply use header files that you created for your own benefit?
There's no particular magic about it (though there're linking issues above to learn about if you put implementation out-of-line), but to start with just throw some code in a file:
#pragma once
...
...then #include it from another file. If the including file is in directory "X", then you can include headers in directory "X" using e.g. #include "the_header.h" - with double-quoted header filename - even if the include directory is not specified to the compiler as a command line argument.
If you have something in your header that's declared but not defined, then you will want a matching .cc/.cpp file with the definition, which you should compile into an object and link with the code using the library. For example:
mylib.h
#pragma one
int fn(); // declared but not defined
mylib.cc
#include "mylib.h"
int fn() { return 42; } // matching definition
cc -c mylib // compile mylib.o
app.cc
#include "mylib.h"
int main()
{
return fn();
}
cc -o app mylib.o
A common use for header files in c++ is to define methods or classes without having to implement them. It's defining an interface, or telling other parts of your program how it can interact with them. It lets the files doing the including know what they need to know about those classes/methods without telling everything they don't. In the case of methods, you know there's a method doSomethingCool, and you know how to interact with it. As long as you know that you can generally just #include whatever header file doSomethingCool is defined in, and then the linker does its magic at compile time and finds where you called doSomethingCool and "hooks it up" so to speak to the actual implementation code, which you may write say in doSomethingCool.cpp.
Works with functions, classes and variables.
In C# or Java, classes are declared and defined at the same time. In C++, the norm is to do that separately. What if we write the whole class in one , say .cpp, file and include that in files that references to it, what kinds of bad thing technically would happen besides a lengthened compilation process?
If your implementation of MyClass is all in the header file MyClass.h then any file you needed to implement MyClass will be included whenever someone includes MyClass.h.
If you change any part of MyClass.h, even if it's trivial (such as adding a comment or even a space) then all files that include it will have to recompile, even if the interface hasn't changed.
Neither of these matters for toy projects, but as you noted, when you have a program that consists of hundreds (or thousands, etc.) of class files, the added compilation time alone makes it worthwhile to separate out implementation from interface.
For instance, if I have the following:
// MyClass.h
#include <iostream>
#include <iomanip>
#include <sstream>
#include <string>
#include "Inventory.h"
class MyClass
{
public:
MyClass();
void processInventory(Inventory& inventory)
{
// Do something with each item in the inventory here
// that uses iostream, iomanip, sstream, and string
}
private:
// ...
};
It would more ideomatically be written as:
// MyClass.h
class Inventory;
class MyClass
{
public:
MyClass();
void processInventory(Inventory& inventory);
private:
// ...
};
// MyClass.cc
#include "MyClass.h"
#include <iostream>
#include <iomanip>
#include <sstream>
#include <string>
#include "Inventory.h"
MyClass()::MyClass()
{
}
void MyClass()::processInventory(Inventory& inventory)
{
// Do something with each item in the inventory here
// that uses iostream, iomanip, sstream, and string
}
Notice: Including MyClass.h doesn't mean iostream, iomanip, sstream, string, or Inventory.h have to be parsed. Changing how processInventory works doesn't mean all files using MyClass.h have to be recompiled.
Notice how much easier it can be to figure out how to use MyClass now. Header files serve an important purpose: they show people how to use your class. With the modified MyClass.h it's easy to see the list of functions. If each function is defined in the header, then you can't look at just the list of functions. That makes it harder to figure out how to use the class.
You may break the one definition rule.
If you write this:
class foo
{
public:
void doit();
};
foo::doit() {}
and include that in multiple classes, you will have multiple definitions of foo::doit and your link will fail.
But if you make all your classes inline, either by defining them within the class declaration:
class foo
{
public:
void doit() {
}
};
or by explicitly making them inline:
class foo
{
public:
void doit();
};
inline void foo::doit() {}
then you can include that file as many times as you like.
The linker will see multiple definitions of the class's members when you try to combine multiple such objects. Thus, you won't be able to produce a binary from source files that include anything in more than one place.
Typically you separate the declaration and definition of a class. This allows you to use your class in different source files by simply including the declaration.
If you include a .cpp which has both declaration and definition into 2 different source files then that class will be doubly defined.
Each .cpp that the class is included into will compile fine into object files. However each class must have only 1 definition total or else you will not be able to link your object files together.
The most important thing to understand about #include contrasted with other languages importing methods, is that #include COPIES the contents of that file where the #include directive is placed. So declaring and defining a class in the same file will create three things:
Significantly increase your compile
times.
If your definitions are not inline
you will get linker errors, since
the compiler finds multiple
definitions to the same functions
That would expose the implementation
to the user, instead of only the interface.
That is why it is common practice to define large classes in separate files, and on some ocassions, really small classes with small implementations (like smart pointers) in one file(To also implicitly inline methods).
#Bill
I think it is important to underscore Bill's point:
Notice how much easier it can be to
figure out how to use MyClass now.
Header files serve an important
purpose: they show people how to use
your class.
the .h file being more or less the "public" doc to allow the understanding of how your class works in some ways conceptually--an Interface. Remember the source file should be thought of as proprietary. I remember learning a lot about how Unix worked in my early C/C++ days by reading header files. Also remember that inline function complexities should be no more than accessor's
A big reason for a class to be defined in a cpp-file is that it isn't needed publically, it is just a helper function (like e.g. a functor). Some people seem to be afraid to put the complete class in the cpp-file, while that just shows your intent of only using the class there.
Files are usually the atoms of your version control system - if you partition things sensibly into different files, then it becomes possible for a team of developers to check out only the parts they each need to work on. Put everything in one file and you can't do that.
Instead of doing
#include "MyClass.cpp"
I would like to do
#include "MyClass.h"
I've read online that not doing so is considered bad practice.
Separate compilation in a nutshell
First, let's get some quick examples out there:
struct ClassDeclaration; // 'class' / 'struct' mean almost the same thing here
struct ClassDefinition {}; // the only difference is default accessibility
// of bases and members
void function_declaration();
void function_definition() {}
extern int global_object_declaration;
int global_object_definition;
template<class T> // cannot replace this 'class' with 'struct'
struct ClassTemplateDeclaration;
template<class T>
struct ClassTemplateDefinition {};
template<class T>
void function_template_declaration();
template<class T>
void function_template_definition() {}
Translation Unit
A translation unit (TU) is a single source file (should be a **.cpp* file) and all the files it includes, and they include, etc. In other words: the result of preprocessing a single file.
Headers
Include guards are a hack to work around lack of a real module system, making headers into a kind of limited module; to this end, including the same header more than once must not have an adverse affect.
Include guards work by making subsequent #includes no-ops, with the definitions available from the first include. Because of their limited nature, macros which control header options should be consistent throughout a project (oddball headers like <assert.h> cause problems) and all #includes of public headers should be outside of any namespace, class, etc., usually at the top of any file.
See my include guard naming advice, including a short program to generate include guards.
Declarations
Classes, functions, objects, and templates may be declared almost anywhere, may be declared any number of times, and must be declared before referring to them in any way. In a few weird cases, you can declare classes as you use them; won't cover that here.
Definitions
Classes may be defined at most once[1] per TU; this typically happens when you include a header for a particular class. Functions and objects must be defined once in exactly one TU; this typically happens when you implement them in a **.cpp* file. However, inline functions, including implicitly inline functions inside class definitions, may be defined in multiple TUs, but the definitions must be identical.
For practical purposes[2], templates (both class templates and function templates) are defined only in headers, and if you want to use a separate file, then use another header[3].
[1] Because of the at-most-once restriction, headers use include guards to prevent multiple inclusion and thus multiple definition errors.
[2] I won't cover the other possibilities here.
[3] Name it blahblah_detail.hpp, blahblah_private.hpp, or similar if you want to document that it's non-public.
Guidelines
So, while I'm sure everything above is all a big ball of mud so far, it's less than a page on what should take up a few chapters, so use it as a brief reference. Understanding the concepts above, however, is important. Using those, here's a short list of guidelines (but not absolute rules):
Always name headers consistently in a single project, such as **.h* for C and **.hpp* for C++.
Never include a file which is not a header.
Always name implementation files (which are going to be directly compiled) consistently, such as **.c* and **.cpp*.
Use a build system which can compile your source files automatically. make is the canonical example, but there are many alternatives. Keep it simple in simple cases. For example, make can be used its built-in rules and even without a makefile.
Use a build system which can generate header dependencies. Some compilers can generate this with command-line switches, such as -M, so you can make a surprisingly useful system easily.
Build Process
(Here's the tiny bit that answers your question, but you need most of the above in order to get here.)
When you build, the build system will then go through several steps, of which the important ones for this discussion are:
compile each implementation file as a TU, producing an object file (**.o*, **.obj*)
each is compiled independently of the others, which is why each TU needs declarations and definitions
link those files, along with libraries specified, into a single executable
I recommend you learn the rudiments of make, as it is popular, well-understood, and easy to get started with. However, it's an old system with several problems, and you'll want to switch to something else at some point.
Choosing a build system is almost a religious experience, like choosing an editor, except you'll have to work with more people (everyone working on the same project) and will likely be much more constrained by precedent and convention. You can use an IDE which handles the same details for you, but this has no real benefit from using a comprehensive build system instead, and you really should still know what it's doing under the hood.
File Templates
example.hpp
#ifndef EXAMPLE_INCLUDE_GUARD_60497EBE580B4F5292059C8705848F75
#define EXAMPLE_INCLUDE_GUARD_60497EBE580B4F5292059C8705848F75
// all project-specific macros for this project are prefixed "EXAMPLE_"
#include <ostream> // required headers/"modules"/libraries from the
#include <string> // stdlib, this project, and elsewhere
#include <vector>
namespace example { // main namespace for this project
template<class T>
struct TemplateExample { // for practical purposes, just put entire
void f() {} // definition of class and all methods in header
T data;
};
struct FooBar {
FooBar(); // declared
int size() const { return v.size(); } // defined (& implicitly inline)
private:
std::vector<TemplateExample<int> > v;
};
int main(std::vector<std::string> args); // declared
} // example::
#endif
example.cpp
#include "example.hpp" // include the headers "specific to" this implementation
// file first, helps make sure the header includes anything it needs (is
// independent)
#include <algorithm> // anything additional not included by the header
#include <iostream>
namespace example {
FooBar::FooBar() : v(42) {} // define ctor
int main(std::vector<std::string> args) { // define function
using namespace std; // use inside function scope, if desired, is always okay
// but using outside function scope can be problematic
cout << "doing real work now...\n"; // no std:: needed here
return 42;
}
} // example::
main.cpp
#include <iostream>
#include "example.hpp"
int main(int argc, char const** argv) try {
// do any global initialization before real main
return example::main(std::vector<std::string>(argv, argv + argc));
}
catch (std::exception& e) {
std::cerr << "[uncaught exception: " << e.what() << "]\n";
return 1; // or EXIT_FAILURE, etc.
}
catch (...) {
std::cerr << "[unknown uncaught exception]\n";
return 1; // or EXIT_FAILURE, etc.
}
This is called separate compilation model. You include class declarations into each module where they are needed, but define them only once.
In addition to hiding implementation details in cpp files (check other replies), you can additionally hide structure details by class forward declaration.
class FooPrivate;
class Foo
{
public:
// public stuff goes here
private:
FooPrivate *foo_private;
};
The expression class FooPrivate says that FooPrivate is completely defined somewhere else (preferably in the same file where Foo's implementation resides, before Foo's stuff comes. This way you make sure that implementation details of Foo(Private) aren't exposed via the header file.
You needn't include .c or .cpp files - the compiler will compile them regardless whether they're #included in other files or not. However, the code in the .c/.cpp files is useless if the other files are unaware of the classes/methods/functions/global vars/whatever that's contained in them. And that's where headers come into play. In the headers, you only put declarations, such as this one:
//myfile.hpp
class MyClass {
public:
MyClass (void);
void myMethod (void);
static int myStaticVar;
private:
int myPrivateVar;
};
Now, all .c/.cpp files that will #include "myfile.hpp" will be able to create instances of MyClass, operate on myStaticVar and call MyClass::myMethod(), even though there's no actual implementation here! See?
The implementation (the actual code) goes into myfile.cpp, where you tell the compiler what all your stuff does:
//myfile.cpp
int MyClass::myStaticVar = 0;
MyClass::MyClass (void) {
myPrivateVar = 0;
}
void MyClass::myMethod (void) {
myPrivateVar++;
}
You never include this file anywhere, it's absolutely not necessary.
A tip: create a main.hpp (or main.h, if you prefer - makes no difference) file and put all the #includes there. Each .c/.cpp file will then only need to have have this line: #include "main.hpp". This is enough to have access to all classes, methods etc. you declared in your entire project :).
You should not include a source file (.c or .cpp). Instead you should include the corresponding header file(.h) containing the declarations. The source files needs to be compiled separately and linked together to get the final executable.
Cpp files should be defined in your compiler script to be compiled as object files.
What ide are you using?
I am going to assume you are compiling with gcc, so here is the command to compile two .cpp files into one executable
gcc -o myclasses.out myclass.cpp myotherclass.cpp
You should only use #include to include class definitions, not the implentation
One thing you will want to watch out for when including you class declarations from a .h/.hpp is make sure it only ever gets included once. If you don't do this you will get some possibly cryptic compiler errors that will drive you up the wall.
To do this you need to tell the compiler, using a #define, to include the file only if the #define does not already exist.
For example (MyClass.h):
#ifndef MYCLASS_H
#define MYCLASS_H
class MyClass
{
// Memebers and methods
}
#endif
// End of file
This will guarantee your class declaration only gets included once even if you have it included in many different .cpp files.