I would like to modify PierreBdR's exception example of how to make a custom exception so that it is visible to other classes. His example works for me but the exception is visible only inside that class.
I'm using MS Visual Studio 2013 and I'm a C++ newbie encumbered by a Java mentality.
Here is what is in the .hpp file:
struct IllegalArgumentException : public std::exception
{
public: IllegalArgumentException(std::string ss);
public: ~IllegalArgumentException();
const char* IllegalArgumentException::what() { return s.c_str(); }
private: std::string s;
};
Here is part of the .cpp file:
IllegalArgumentException::IllegalArgumentException(std::string ss) : s(ss) {}
IllegalArgumentException::~IllegalArgumentException() {}
const char * IllegalArgumentException::what() { return s.c_str(); }
I'm getting:
error C2011: 'IllegalArgumentExcpetion': 'struct' type redefinition (.hpp file)
Point 1
const char* IllegalArgumentException::what() { return s.c_str(); }
is declared incorrectly if declared inside a class or struct. Since the declaration is being made inside the IllegalArgumentException class, IllegalArgumentException:: is implied and messes with the compiler because the compiler now thinks you are declaring something else. You want
const char* what() { return s.c_str(); }
In addition, the { return s.c_str(); } portion implements the function, so there is no need to implement it in the cpp file.
Point 2
Everything in a struct is public unless declared following the private keyword. This is the opposite of a class where everything is private unless stated otherwise. A class and a struct are pretty much identical other than the difference on default access.
Point 3
In C++ you can declare access level of members in blocks. There is no need to declare the access level of members one at a time.
struct IllegalArgumentException : public std::exception
{
// these are all public by default in a struct
IllegalArgumentException(std::string ss);
~IllegalArgumentException();
const char* IllegalArgumentException::what() { return s.c_str(); }
private: // everything after this is private
std::string s;
int example;
};
or
class IllegalArgumentException : public std::exception
{
public: // these are all private by default in a class and need to be public
IllegalArgumentException(std::string ss);
~IllegalArgumentException();
const char* IllegalArgumentException::what() { return s.c_str(); }
private: // switch back to private
std::string s;
int example;
};
or
class IllegalArgumentException : public std::exception
{
// these are all private by default in a class
std::string s;
int example;
public: // everything after this is public
IllegalArgumentException(std::string ss);
~IllegalArgumentException();
const char* IllegalArgumentException::what() { return s.c_str(); }
};
Point 4
IllegalArgumentException::~IllegalArgumentException() {}
doesn't do anything. It doesn't need to do anything so the Rule of Zero recommends against having a destructor at all. The compiler will create it for you. If you don't have to write it, don't write it because code that doesn't exist has no bugs.
class IllegalArgumentException : public std::exception
{
// these are all private by default
std::string s;
int example;
public: // everything after this is public
IllegalArgumentException(std::string ss);
const char* IllegalArgumentException::what() { return s.c_str(); }
};
Point 5
Stealing from KerrekSB here because it's a point that OP had another question on. Use Include Guards
Include guards prevent a header from being included multiple times in the same translation unit. This is a problem because of bloat and the possibility of the same thing being defined or declared more than once leading to confusion about which is the real one.
A simple header guard:
#ifndef ILLEGALARGUMENTEXCEPTION_H // if we've never seen ILLEGALARGUMENTEXCEPTION_H
// before, do the following
#define ILLEGALARGUMENTEXCEPTION_H // OK we've seen it now!
// all subsequent includes of IllegalArgumentException.h will have seen
// ILLEGALARGUMENTEXCEPTION_H and fail the ifndef, skipping everything
// until it finds the closing #endif
#include <string>
#include <exception>
class IllegalArgumentException : public std::exception
{
// these are all private by default
std::string s;
int example;
public: // everything after this is public
IllegalArgumentException(std::string ss);
const char* IllegalArgumentException::what() { return s.c_str(); }
};
#endif // end of Include Guard
You may also use #pragma once, but be warned that #pragma means non-standard compiler extension. once may not exist for your compiler and if it doesn't, the compiler is allowed to skip the instruction without telling you!
There are many reasons why once is not in the standard, most important is it has unresolved fail cases. Use it with caution.
You mixed up the what() function's declaration and definition. You tried refer to the function with the scope resolution operator (i.e ::). In this case it should be done in the definition (i.e in the .cpp file)
Also the what() function was implemented as an inline function in your .hpp file, which means that you don't need to define it again in the .cpp file. Therefore you got a redefinition of ‘const char* IllegalArgumentException::what() error.
P.S: In C++ class declarations one does not need to specify every attribute/method's access modifier, you can just group them under a single modifier.
.hpp file:
struct IllegalArgumentException : public std::exception
{
public:
IllegalArgumentException(std::string ss);
~IllegalArgumentException();
const char* what() { return s.c_str(); }
private:
std::string s;
};
.cpp file:
IllegalArgumentException::IllegalArgumentException(std::string ss) : s(ss) {}
IllegalArgumentException::~IllegalArgumentException() {}
It seems you are possibly, perhaps indirectly, including the .hpp file more than once?
#include is a fairly primitive way to share code among several .cpp files: it tells the compiler (the preprocessor, specifically) to import the contents of the .hpp right there at that spot in the code. Then in a later pass, the compiler will compile the entire thing as if it is all one file. (There's a whole crazy turing-complete language for that preprocessor step; IMO you should avoid it as much as possible, mostly only using it for the stuff outlined in this note.)
One problem with this approach is that if you end up importing one .hpp file more than once – a very common thing to do, since .hpp files typically include other .hpp files – you will have that code repeated. It's illegal to define a struct or class more than once, so you get the error about "type redefinition".
The solution is to use include guards in every single .hpp file. At the very top, use lines like:
#ifndef SOME_STRING_THAT_UNIQUELY_IDENTIFIES_THIS_HEADER
#define SOME_STRING_THAT_UNIQUELY_IDENTIFIES_THIS_HEADER
Then at the very bottom of the .hpp file:
#endif // SOME_STRING_THAT_UNIQUELY_IDENTIFIES_THIS_HEADER
Those preprocessor directives, #ifndef, #define, etc will remove any text in the middle if the big unique string is already defined. Usually your codebase will establish conventions for that big string, such as encoding the path into it. My company even uses a lint tool to make sure you encoded it correctly.
This ensures that if you #include a .hpp twice, or #include another .hpp that includes an already-included .hpp, you will get the contents of the .hpp file exactly once in the final preprocessor output.
This, and the preprocessor in general, is one of the less charming parts of C++ that really shows its age. Soon the language will be getting a much more modern and pleasant system for sharing interfaces called "modules". In the meantime, each .hpp needs these 3 lines of boilerplate.
I am not sure, but I can comment so...
I think your "what" function is two times implemented:
First in your hpp file and then in the cpp file.
Related
I want to Use one globe variable in all cpp files.If one class of the cpp file changed the value,I want to access it from another class cpp file,which is the value that least modified by any other cpp class file.
str.h - global variable file
#ifndef MY_PROG
#define MY_PROG
extern char * myname;
#endif
class1.cpp
#include "str.h"
char * myname;
class class1
{
class1(){}
~class1(){}
void Setname1(char *name) { myname = name }
};
class2.cpp
#include "str.h"
char * myname;
class class2
{
class2(){}
~class2(){}
void setName(char *name) { myname = name }
};
class3.cpp
#include "str.h"
class class3
{
class3(){}
~class3(){}
char *GetData()
{
return myname;
}
};
main.cpp
#include "str.h"
int main()
{
class1 c1;
class2 c2;
c1.Setname1("XXXX");
c2.setname("YYYY");
class3 c3;
cout << c3.GetData;
}
when I execute the program, I need to get Last modified value that is "YYYY" .I am new to cpp, And also please tell me whether I used the extern keyword correctly.If not , please provide me the right procedure.
The essential in your problem is understanding the difference between declarations and definitions of variables (and types, functions etc. objects in C/C++)
extern char * myname; is a declaration. It makes myname visible to other pieces of code in the same file so that they can reference it.
char * myname; is a definition. Not only it makes myname visible, it also instructs the compiler to allocate space for it and to make its address known.
You can have as many declarations of the same variable in your code as you want, as long as they do not contradict each other. No so with definitions. If you define a thing two times, it would need to be assigned two addresses, and then how can other object files "understand" which address to use when referencing it? The same goes with the space allocated — what to do with the extra piece of it allocated? This is the error that you see.
To make the code work, have only one and exactly one definition of myname in exactly one file. It must not be a header file because it gets copied into multiple source files thus creating multiple definitions. It can be any other C++ file though.
In the rest of the files (or in a single header included in all of them) have multiple declarations of myname if it is referenced in a particular file. If not, you can omit it for a particular unit.
All this being said, it is considered to be a VERY BAD PRACTICE to communicate data between compilation units through global mutable shared variables. They make code a nightmare to debug and understand and impossible to parallelize. Nobody ever thinking getting money for the code they write should use them. Instead, the best approach would be to pass a mutable object as one of methods/functions argument. Details actually depend on the rest of your application.
If I have a simple header file:
namespace aNamespace {
class AClass {
public:
AClass();
~AClass();
bool Init();
void Shutdown();
};
}
What is the 'correct' way to implement this class in the corresponding CPP file? I can see two options:
Option A
namespace aNamespace {
class AClass {
public:
AClass() { ... }
~AClass() { ... }
bool Init() { ... }
void Shutdown() { ... }
};
}
Option B
namespace aNamespace {
AClass::AClass() { ... }
AClass::~AClass() { ... }
bool AClass::Init() { ... }
void AClass::Shutdown() { ... }
}
The problem I see with Option B is that it's hard to add implementation-specific members to AClass - e.g. what if the implementation requires a std::wstring or so as a storage variable; but that variable isn't defined in the header file?
The reason I'm asking this is because I may wish to have multiple implementations of AClass, and select which one to link according to some external variable (e.g. the target platform or architecture).
Another option would be to actually make name of each implementation platform specific and have a simple typedef switch in header to control which one is chosen based on target/architecture:
#ifdef target1
typedef AClass Target1ClassImplementation;
#elif defined target2
typedef AClass Target2ClassImplementation;
#else
#error AClass is not implemented for current target
#endif
If desired, common interface can be encapsulated in a base class implementations derive from. It is less error prone since is more explicit in sense which implementation is for what target, while allows using AClass regardlesss of a platform target outside of header.
B is much better in most cases:
Advantages:
Hide implementation details.
Less #includes in header files (less exposed dependencies!):
Faster builds
2 classes can call each other's functions. Very tricky to do if both are in headers.
Changes to implementation do affect other classes (build time).
Disadvantages:
- Functions in CPP file do not inline in other modules (across library boundaries)
Optimal: Decide per function which is best. Short one liners to the header and longer ones to the cpp(s). You can have more than 1 source file for the class implementation.
I am programming on linux using g++ and I often encounter the problem that I need to use a class or data type in a header file which I define later, either at a later point in the header or in another header file.
For instance look at this header file:
class example
{
mydatatype blabla;
};
struct mydatatype
{
int blablainteger;
char blablachar;
};
This will give error because mydatatype is used before its defined
so usually I change it like this:
struct mydatatype; // <-- class prototype
class example
{
mydatatype *blabla; // <-- now a pointer to the data type
// I will allocate the data during runtime with the new operator
};
struct mydatatype
{
int blablainteger;
char blablachar;
};
Now it works. I could often just put the definition above, or include the header which is needed, but I don't want to include headers in a header or juggle with the definition order, it always gets messy.
The solution I showed usually works, but now I have encountered a new phenomenon. This time the datatype is not a class but a typedef, I cant use prototypes for a typedef and I don't want to use the actual datatype which the typedef incorporates.. it's messy too.
Is there any solution to this?
Firstly, the solution you've thought of (prototype and pointer), is unneeded, and slower than just implementing it without the pointer.
The "proper" solution for this, would be creating seperate headers for each type, and then include them in your other header. That way it will always be defined! You can even make them so that they include eachother.
However, if you've ever opened a .h file provided by g++, you've most likely seen this at the start of the header:
#ifndef SOMETHING_H
#define SOMETHING_H
// Code
#endif /* SOMETHING_H */
This is to solve the issue of types redefining themselves.
If they weren't there, and you included the header file multiple times, the types would be redefined, and an error would be thrown. This makes it so that the types are always present, but never included twice.
I hope that helps!
Place each class/type in it's own header file, and then include the relevant header file in other headers where you need it. Use an inclusion guard in each header e.g.:
// SomeHeaderFile.h
#ifndef SOME_HEADER_FILE_H
#define SOME_HEADER_FILE_H
// code
#endif
I disagree that this is messy - it allows you have an organised structure to you project, it allows each class to operate independently of others and without worrying about order, and it's a good idea to place each class in it's own file anyway.
You could just define the class inside the other class like
template<class T>
class vertex {
private:
class edge {
public:
vertex<T> *to;
double weight;
edge() {
weight = INFINITY;
to = NULL;
};
} *paths;
T data;
unsigned nof_paths;
public:
vertex(T val) {
data = val;
paths = NULL;
nof_paths = 0;
}
void addPathTo(vertex<T>*&);
edge* getAllPaths() {
return paths;
};
};
Obviously this works for small classes... if your class is ENORMOUS you'll be better using separate header files like the other guys said.
I'm trying to find a clean way to separate implementation details in C++ header files in a big project in order to achieve better information hiding and reduce build time. The problem with C++ is that every time you change a private member declaration, your dependent classes must be rebuilt.
This is a solution I came up with. Is it any good?
The basic Idea is to include a part of the cpp file conditionally in the header. this part contains the implementation declarations and is included only when the implementation file includes the header. in case of the external classes, this details are excluded from header. so client and implementation see two different version of header file. internal declaration changes won't affect clients(no compilation of dependent classes) and headers won't include private details.
Here is the implementation:
HEADER
#pragma once
class Dependency
{
public:
Dependency(void);
~Dependency(void);
void Proc(void);
//PRIVATE Implementaion details stays private
#ifdef Dependency_PRIVATE_IMPELEMENTATION
#define Dependency_PRIVATE_MODE 1
#include "Dependency.cpp"
#undef Dependency_PRIVATE_MODE
#endif
};
CPP
#define Dependency_PRIVATE_IMPELEMENTATION
#include "Dependency.h"
#undef Dependency_PRIVATE_IMPELEMENTATION
#ifdef Dependency_PRIVATE_MODE
private:
int _privateData;
#else
#include <iostream>
Dependency::Dependency(void)
{
//This line causes a runtime exception, see client
Dependency::_privateData = 0;
}
Dependency::~Dependency(void)
{
}
void Dependency::Proc(void)
{
std::cout << "Shiny happy functions.";
}
#endif
CLIENT
#include "stdafx.h"
#include "Dependency.h"
#pragma message("Test.Cpp Compiled")
int _tmain(int argc, _TCHAR* argv[])
{
Dependency d;
d.Proc();
return 0;
//and how I have a run time check error #2, stack around d ?!!
}
It's a pretty interesting question, really. Managing dependencies is important for big projects because the build times ramp up can make even the simplest change daunting... and when it happens people will try to hack it to avoid the rebuild-of-death (tm).
Unfortunately, it does not work.
The Standard explicitly says that classes definitions appearing in different translation units (roughly, files) should obey the One Definition Rule (see § 3.2 One definition rule [basic.def.odr]).
Why ?
The problem is a matter of impedance, in a way. The definition of a class contains information on the class ABI (Application Binary Interface), most notably, how such a class is layed out in memory. If you have different layouts of the same class in various translation units, then when putting it altogether, it won't work. It's as if one TU was speaking German and the other Korean. They might be attempting to say the same thing, they just won't understand each other.
So ?
There are several ways to manage dependencies. The main idea is that you should struggle, as much as possible, to provide "light" headers:
include as few things as possible. You can forward declare: types that are shown as arguments or return of functions declaration, types that are passed by reference or pointer but otherwise unused.
hide implementation details
Hum... What does it mean :x ?
Let's pick a simple example, shall we ?
#include "project/a.hpp" // defines class A
#include "project/b.hpp" // defines class B
#include "project/c.hpp" // defines class C
#include "project/d.hpp" // defines class D
#include "project/e.hpp" // defines class E
namespace project {
class MyClass {
public:
explicit MyClass(D const& d): _a(d.a()), _b(d.b()), _c(d.c()) {}
MyClass(A a, B& b, C* c): _a(a), _b(b), _c(c) {}
E e() const;
private:
A _a;
B& _b;
C* _c;
}; // class MyClass
} // namespace project
This header pulls in 5 other headers, but how many are actually necessary ?
a.hpp is necessary, because _a of type A is an attribute of the class
b.hpp is not necessary, we only have a reference to B
c.hpp is not necessary, we only have a pointer to C
d.hpp is necessary, we call methods on D
e.hpp is not necessary, it only appears as a return
OK, let's clean this up!
#include "project/a.hpp" // defines class A
#include "project/d.hpp" // defines class D
namespace project { class B; }
namespace project { class C; }
namespace project { class E; }
namespace project {
class MyClass {
public:
explicit MyClass(D const& d): _a(d.a()), _b(d.b()), _c(d.c()) {}
MyClass(A a, B& b, C* c): _a(a), _b(b), _c(c) {}
E e() const;
private:
A _a;
B& _b;
C* _c;
}; // class MyClass
} // namespace project
Can we do better ?
Well, first we can see that we call methods on D only in the constructor of the class, if we move the definition of D out of the header, and put it in a .cpp file, then we won't need to include d.hpp any longer!
// no need to illustrate right now ;)
But... what of A ?
It is possible to "cheat", by remarking that merely holding a pointer does not requires a full definition. This is known as the Pointer To Implementation idiom (pimpl for short). It trades off run time for lighter dependencies, and adds some complexity to the class. Here is a demo:
#include <memory> // don't really worry about std headers,
// they are pulled in at one time or another anyway
namespace project { class A; }
namespace project { class B; }
namespace project { class C; }
namespace project { class D; }
namespace project { class E; }
namespace project {
class MyClass {
public:
explicit MyClass(D const& d);
MyClass(A a, B& b, C* c);
~MyClass(); // required to be in the source file now
// because for deleting Impl,
// the std::unique_ptr needs its definition
E e() const;
private:
struct Impl;
std::unique_ptr<Impl> _impl;
}; // class MyClass
} // namespace project
And the corresponding source file, since that were the interesting things occur:
#include "project/myClass.hpp" // good practice to have the header included first
// as it asserts the header is free-standing
#include "project/a.hpp"
#include "project/b.hpp"
#include "project/c.hpp"
#include "project/d.hpp"
#include "project/e.hpp"
struct MyClass::Impl {
Impl(A a, B& b, C* c): _a(a), _b(b), _c(c) {}
A _a;
B& _b;
C* _c;
};
MyClass::MyClass(D const& d): _impl(new Impl(d.a(), d.b(), d.c())) {}
MyClass::MyClass(A a, B& b, C* c): _impl(new Impl(a, b, c)) {}
MyClass::~MyClass() {} // nothing to do here, it'll be automatic
E MyClass::e() { /* ... */ }
Okay, so that was the low and gritty. Further reading:
The Law of Demeter: avoid having to call multiple methods in sequences (a.b().c().d()), it means you have leaky abstraction, and forces you the include the whole world to do anything. Instead, you should be calling a.bcd() which hides the details from you.
Separate your code into modules, and provide a clear-well defined interface to each module, normally, you should have far more code within the module than on its surface (ie exposed headers).
There are many ways to encapsulate and hide information, your quest just begins!
This does not work. If you add anything to the class in the private .cpp file, the the users of the class will see a different class than what your implementation thinks it is.
This is not legal, and won't work in many cases. KDE has a great article on what you can and can't change in C++ to preserve ABI compatibility: Binary Compatibility Issues. If you break any of that with your "hidden" implementation, you're going to break the users.
Look at the pimpl idiom for a rather common way of doing what you are trying to achieve.
This won't work. You can easily see it because sizeof(Dependency) for the implementation and the client are different. The client basically sees a different class, accesses different locations in the memory and everything messes up!
Unfortunately, you cannot prevent a rebuild of dependent files if you change a class. However, you can hide the implementation details like this:
Header:
class privateData;
class Dependency
{
private:
privateData *pd;
public:
Dependency(void);
~Dependency(void);
void Proc(void);
};
cpp file
#include <Dependency.h>
class privateData
{
/* your data here */
};
Dependency::Dependency()
{
pd = new privateData;
}
Dependency::~Dependency()
{
if (pd)
delete pd;
}
void Dependency::Proc()
{
/* your code */
}
Note that this is not for you to copy paste. It's just to give you the idea. There may be missing error checking or code that is implied by this usage. One such thing is a copy constructor to prevent shallow copies.
Look at the Opaque_pointer pattern (aka pImpl)
The pattern is typically used for when the Class want to hide the internal implementation but is also have the benefit of that changes to the internal and private structures does not create a recompile since the binary call compatibility is maintained.
The problem with doing it any other way, is that binary compatibility is probably NOT maintained when you changed anything in the class definition, and hence all software will have to be recompiled.
It looks like your solution is a attempt to do exactly this, however you should user a (void*) instead of a int so as to make sure the software compiles correctly on 32 and 64 bit compilers on different platforms -- and just use the cook-book example of Opaque Pointers.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is an undefined reference/unresolved external symbol error and how do I fix it?
I'm relatively new to C++ (as you can probably tell by the question) and I've hit a problem. I have two files: Drives.h and Drives.cpp
Drives.h
#pragma once
enum MountMode
{
User,
System,
Both,
Auto
};
class Drive
{
public:
Drive(void);
~Drive(void);
BOOL Mount(MountMode mode);
VOID Unmount(void);
BOOL IsConnected(void);
static char* DeviceName;
static char* DrivePath;
};
class Drives
{
public:
Drives(void);
~Drives(void);
};
and my Drives.cpp:
#include "stdafx.h"
#include "Drives.h"
Drives::Drives(void)
{
Drive USB0; //Error happening here
}
Drives::~Drives(void)
{
}
The error is saying that the Drives class constructor, destructor and IsConnected() are all unresolved externals. I'm not sure what I'm missing since I set this class up like the one on cplusplus.com
Thanks in advance
As the error message says, you have not implemented the constructor and destructor of Drive:
Drive::Drive(void) {
...
}
Drive::~Drive(void) {
...
}
Creating a local variable of class type (as you do in Drive USB0;) will invoke that class' constructor, and the destructor will be invoked at the end of the variable's scope; hence the error.
You should implement the other functions of Drive too - declaring a function in a class declaration is essentially a promise that the function will be implemented somewhere.
Yes, those methods have been declared in the Drive class in your header file, but you haven't actually created a body for these methods.
You must either create a body inline in your header file, create a body in a CPP file, or make sure you are linking with an existing file that defines these methods. Otherwise, the error is right, these methods have not been defined.
An Unresolved External Symbol error usually means you have provided a declaration of a function but not its definition.
In your case, since you declared Drive(void) and ~Drive(void) the compiler removes its defaults and expects your definitions to exist, which they don't, so it throws an error.
As a side note: using void in place of empty parenthesis to mean "This function takes no arguments" is a C-Style definition and should not be used.
Also,do not use #pragma once as a substitute for include guards. It is a Microsoft-Specific construct and is not compatible with other compilers. Use actual include guards instead:
#ifndef CLASS_NAME_H
#define CLASS_NAME_H
//CODE HERE
#endif
In the following code you declare two classes(Drive and Drives), but you provide the implementation only for one (Drives)
#pragma once
enum MountMode
{
User,
System,
Both,
Auto
};
class Drive
{
public:
Drive(void);
~Drive(void);
BOOL Mount(MountMode mode);
VOID Unmount(void);
BOOL IsConnected(void);
static char* DeviceName;
static char* DrivePath;
};
class Drives
{
public:
Drives(void);
~Drives(void);
};
To get rid of the error message, you must include an implementation for Drive's class methods. On way to extend your Drives.cpp so that your code may work looks like this:
#include "stdafx.h"
#include "Drives.h"
//Drive class constructor
Drive::Drive(void)
{
//Add initialization code here. For example:
DeviceName = "Name";
DrivePath = "";
}
//Drive class destructor
Drive::~Drive(void)
{
}
//Also add the implementation for Mount
BOOL Drive::Mount(MountMode mode)
{
//implementation for Mount. For example:
return FALSE;
}
//Also add the implementation for Mount
VOID Drive::Unmount()
{
//implementation for Unmount
}
//Also add the implementation for Mount
BOOL Drive::IsConnected()
{
//implementation for IsConnected.For example:
return FALSE;
}
//Drives class constructor
Drives::Drives(void)
{
Drive USB0; //Error happening here
}
//Drives class destructor
Drives::~Drives(void)
{
}
It is also possible if you copy paste-d the code, that you also have the implementation for the Drive class but you save it in another .cpp file, like Drive.cpp. In that case you should either copy all the implementation methods from the other Drive.cpp file to Drives.cpp. Or you should move the declaration of Drive class from Drives.h to Drive.h. In that case you will have clear separation for classes in different files, which is good, but you will have to include Drive.h in the Drives.h file.