Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 8 years ago.
Improve this question
i'm new to c++ (i had some time with Java and C before)
i can't get it... eclipse is creating header and cpp files when i want to create some new class, why ? thing is , it seems like the header includes the class basic implantation so what does the cpp file is being used ?
header:
#ifndef HEAP_H_
#define HEAP_H_
namespace std {
class Heap {
public:
Heap();
virtual ~Heap();
};
} /* namespace std */
#endif /* HEAP_H_ */
cpp:
#include "Heap.h"
namespace std {
Heap::Heap() {
// TODO Auto-generated constructor stub
}
Heap::~Heap() {
// TODO Auto-generated destructor stub
}
} /* namespace std */
the object oriented thinking in c++ just seems weird. what's the point of an header file when you have a class file with methods ?
anyway , thx ahead!
The header file is where the declaration of the class is. This is done so that multiple files are able to include the Heap class.
You COULD just write the implementation in the header file by itself, but then you wouldn't be able to include it in more than one file due to the method/class/whatever being declared multiple times. This is actually true in C as well. If you create an include file:
int double_me(int number) {
return number * 2;
}
And then include that in multiple files, the compiler will complain about the same method being declared multiple times.
That being said, the header file is where all the class functions and variables are declared. The .cpp source file is where the implementation is written.
For instance, if you wanted to add a method to the Heap class:
Heap.h:
#ifndef HEAP_H_
#define HEAP_H_
namespace std {
class Heap {
public:
Heap();
virtual ~Heap();
void do_nothing(int some_parameter);
};
} /* namespace std */
#endif /* HEAP_H_ */
Heap.cpp:
#include "Heap.h"
namespace std {
Heap::Heap() {
// TODO Auto-generated constructor stub
}
Heap::~Heap() {
// TODO Auto-generated destructor stub
}
void Heap::do_nothing(int some_parameter) {
}
Another advantage is for reduced compile times. If a recompile was to take place, but the Heap object file was not changed, then it won't have to recompile the Heap implementation.
It is pretty standard for a C++ class to have both a header file and an implementation file. The reason for this is that it is common for other functions which use the class to need to know the way in which to make calls to the class (found in the header file), while they don't need to know how those calls are actually implemented. The only functions that are implemented in a header file should be inline (which get moved into the calling function), or template functions.
In fact, if the compiler implements the same function multiple times into multiple object (*.o) files, it will come back with an error during linking. This is the same as it is with C implementation files header files. The header file contains the prototypes, and the implementation file contains the, well, implementation.
Related
I am developing a project in which I have a vendor library, say vendor.h, for the specific Arduino-compatible board I'm using which defines class HTTPClient that conflicts with an Arduino system library, HTTPClient.h, which also defines class HTTPClient.
These two classes are unrelated other than having the same name, and the vendor implementation of an HTTP client is far less capable than the Arduino system library's implementation, so I'd prefer to use the latter. But I can't omit including the former, because I need quite a bit from the vendor.h. Essentially, I have the problem posed here, but with classes rather than functions. I have the full code of both, but given that one is a system library and the other is a vendor library, I'm reluctant to fork and edit either, as that adds lots of merging work down the road if either of them are updated, so my preference would be to find a tidy solution that doesn't edit either header.
I've tried a variety of solutions posted in other SO questions:
I do not want to leave out either header, as I need vendor.h for quite a few things and need the capabilities of HTTPClient.h's client implementation
Proper namespaces in the headers would solve the problem, I would prefer to avoid editing either header
I tried wrapping the #include <HTTPClient.h> in a namespace in my main.cpp, but that caused linking errors, as it's not a header-only library, so the header & cpp weren't in the same namespace
I tried a simple wrapper as proposed for the function in the above linked SO question in which the header contained just a forward declaration of my wrapper class & the associated cpp contained the actual class definition. This gave a compiler error of error: aggregate 'HTTP::Client client' has incomplete type and cannot be defined (Code sample of this attempt below)
main.cpp:
#include <vendor.h>
#include "httpclientwrapper.h"
HTTP::Client client;
httpclientwrapper.h:
#ifndef INC_HTTPCLIENTWRAPPER_H
#define INC_HTTPCLIENTWRAPPER_H
namespace HTTP {
class Client;
}
#endif
httpclientwrapper.cpp:
#include "httpclientwrapper.h"
#include <HTTPClient.h>
namespace HTTP {
class Client : public ::HTTPClient {};
}
In that example, I can't inherit from HTTPClient in a class definition in my header, as that will reintroduce the duplicate class name to the global namespace in my main program (hence the perhaps misguided attempt to see if a forward declaration would do the trick). I suspect that I can resolve the issue by completely duplicating the class definition of HTTPClient in my wrapper class above rather than trying to use inheritance. I would then add member definitions to my wrapper cpp which pass the call to HTTPClient's members. Before I go through the trouble of rewriting (or more likely, copy/pasting) the entire HTTPClient definition from HTTPClient.h into my own wrapper, I was wondering if there was a better or more proper way to resolve the conflict?
Thanks for you help!
As a solution was never proposed, I'm posting an answer that summarizes my research and my ultimate resolution. Mostly, I encourage the use of namespaces, because proper uses of namespaces would have eliminated the conflict. However, Arduino environments try to keep things simple to lower the barrier of entry, eschewing "complicated" features of C++, so more advanced use cases will likely continue to run into issues like this. From other SO answers and forum posts (cited where I could), here are some methods for avoiding name conflicts like this:
If you can edit the source
Edit the source code to remove the conflict or add a namespace to one of both libraries. If this is an open source library, submit a pull request. This is the cleanest solution. However, if you can't push your changes back upstream (such as when one is a system library for some hardware), you may end up with merge issues down the road when the maintainer/developer updates the libraries.
If you can't edit the source
Credit for part of this: How to avoid variable/function conflicts from two libraries in C++
For libraries that are header only libraries (or all functions are inline)
(ie, they have only a .h file without a .o or .cpp)
Include the library inside a namespace. In most code, this is frowned upon as poor form, but if you're already in a situation where you are trying to cope with a library that doesn't contain itself nicely, it's a clean and simple way to contain the code in a namespace and avoid name conflicts.
main.cpp
namespace foo {
#include library.h
}
int main() {
foo::bar(1);
}
For libraries with functions
The above method will fail to link at compile time, because the declarations in the header will be inside the namespace, but the definitions of those functions are not.
Instead, create a wrapper header and implementation file. In the header, declare your namespace and functions you wish to use, but do not import the original library. In the implementation file, import your library, and use the functions inside your new namespaced functions. That way, the one conflicting library is not imported into the same place as the other.
wrapper.h
namespace foo {
int bar(int a);
}
wrapper.cpp
#include "wrapper.h"
#include "library.h"
namespace foo {
int bar(int a) {
return ::bar(a);
}
}
main.cpp
#include "wrapper.h"
int main() {
foo::bar(1);
}
You could also, for the sake of consistency, wrap both libraries so they're each in their own namespace. This method does mean that you will have to put in the effort to write a wrapper for every function you plan to use. This gets more complicated, however, when you need to use classes from the library (see below).
For libraries with classes
This is an extension of the wrapper function model from above, but you will need to put in more work, and there are a few more drawbacks. You can't write a class that inherits from the library's class, as that would require importing the original library in your wrapper header prior to defining your class, so you must write a complete wrapper class. You also cannot have a private member of your class of the type from the original class that you can delegate calls to for the same reason. The attempt at using a forward declaration I described in my question also did not work, as the header file needs a complete declaration of the class to compile. This left me the below implementation, which only works in the cases of a singleton (which was my use case anyway).
The wrapper header file should almost completely duplicate the public interface of the class you want to use.
wrapper.h
namespace foo {
Class Bar() {
public:
void f(int a);
bool g(char* b, int c, bool d);
char* h();
};
}
The wrapper implementation file then creates an instance and passes the calls along.
wrapper.cpp
#include "wrapper.h"
#include "library.h"
namespace foo {
::Bar obj;
void Bar::f(int a) {
return obj.f(a);
}
bool Bar::g(char* b, int c, bool d) {
return obj.g(b, c, d);
}
char* Bar::h() {
return obj.h();
}
}
The main file will interact with only a single instance of the original class, no matter how many times your wrapper class in instantiated.
main.cpp
#include "wrapper.h"
int main() {
foo::Bar obj;
obj.f(1);
obj.g("hello",5,true);
obj.h();
}
Overall, this strikes me as a flawed solution. To fully wrap this class, I think the this could be modified to add a factory class that would be fully contained inside the wrapper implementation file. This class would instantiate the original library class every time your wrapper class is instantiated, and then track these instances. In this way, your wrapper class could keep an index to its associated instance in the factory and bypass the need to have that instance as its own private member. This seemed like a significant amount of work, and I did not attempt to do so, but would look something like the code below. (This probably needs some polish and a real look at its memory usage!)
The wrapper header file adds a constructor & private member to store an instance id
wrapper.h
namespace foo {
Class Bar() {
public:
Bar();
void f(int a);
bool g(char* b, int c, bool d);
char* h();
private:
unsigned int instance;
};
}
The wrapper implementation file then adds a factory class to manage instances of the original library's class
wrapper.cpp
#include "wrapper.h"
#include "library.h"
namespace foo {
class BarFactory {
public:
static unsigned int new() {
instances[count] = new ::Bar();
return count++;
}
static ::Bar* get(unsigned int i) {
return instances[i];
}
private:
BarFactory();
::Bar* instances[MAX_COUNT]
int count;
};
void Bar::Bar() {
instance = BarFactory.new();
}
void Bar::f(int a) {
return BarFactory.get(i)->f(a);
}
bool Bar::g(char* b, int c, bool d) {
return BarFactory.get(i)->g(b, c, d);
}
char* Bar::h() {
return BarFactory.get(i)->h();
}
}
The main file remains unchanged
main.cpp
#include "wrapper.h"
int main() {
foo::bar obj;
obj.f(1);
obj.g("hello",5,true);
obj.h();
}
If all of this seems like a lot of work, then you're thinking the same thing I did. I implemented the basic class wrapper, and realized it wasn't going to work for my use case. And given the hardware limitations of the Arduino, I ultimately decided that rather than add more code to be able to use the HTTPClient implementation in either library, I wrote my own HTTP implementation library in the end, and so used none of the above and saved several hundred kilobytes of memory. But I wanted to share here in case somebody else was looking to answer the same question!
I have written a simple templated, module-based header library. With module-based, I mean that one can include only string.h or dynarray.h and the header will pull in all of its dependencies.
Now I'm facing an issue with missing types because of the way this system works.
A module does:
#include all dependencies
Define an interface class Foo
#include an implementation file
Unfortunately, in some situations, two interfaces need to be available before including any implementations. I have broken down the problem here:
string.h
#pragma once
// A string depends on a DynArray.
#include "dynarray.h"
template<typename E>
class String {
public:
DynArray<E> arr;
/* ... */
};
// Include the implementation of all the different functions (irrelevant here)
#include "string_impl.h"
dynarray.h
#pragma once
// The dynarray header has no direct dependencies
template<typename E>
class DynArray {
public:
/* ... */
E& Get(int index);
};
// Include the implementation of all the different functions
#include "dynarray_impl.h"
dynarray_impl.h
#pragma once
// The dynarray implementation needs the OutOfRangeException class
#include "out_of_range_exception.h"
template<typename E>
E& DynArray<E>::Get(int index) {
if (index >= size) {
throw OutOfRangeException("Some error message");
}
}
out_of_range_exception.h
class OutOfRangeException {
public:
String message;
OutOfRangeException(String message) {
/* ... */
}
};
Due to including the implementation of a module at its bottom, when including string.h somewhere, the content of dynarray_impl.h and with it out_of_range_exception.h comes before the string class interface. So String is not defined in OutOfRangeException.
Obviously, the solution is to delay only the implementation part of dynarray (dynarr_impl.h) after the definition of the string interface. The problem is that I have no idea how to do this without creating some kind of common header file, which is not compatible with a module based approach.
Your problem is that you have one file for both interface and implementation.
#includeing that file represents both depending on the interface of X and the implementation of X.
Sometimes you just want to depend on the interface of X.
X interface:
#include all dependencies of the interface
Define an interface class X.
X implementation:
#include the interface
#include all dependencies of the implementation
Define the implementation of class X.
In a sense, these are two separate modules, where one depends on the other. This permits clients to depend only on the interface of another type, or only on its implementation, or first on the interface, then later on the implementation.
Usually you can just #include "X.h", except when you have a circular dependency of implementations. Then somewhere you have to break the chain with a #include "X_interface.h"
If you really want to use a single header file, you can do away with #pragma once and have header files that can be included in "two modes". This can massively slow down build times as any such mechanism will require the compiler to open files just to check if there is any code there; most compilers can detect #ifdef header-guards and #pragma once and avoid reopening files it knows won't contain anything of interest. But a fancy "can be included multiple times in different modes" header file cannot be handled by that technique.
I know this is a commonly asked question about C++ but following advice of other answers and such, I am still unable to get my seemingly simple code to work. My problem is the following code gives "error: redefinition of 'class Communicator'":
global.h
#ifndef GLOBAL_H
#define GLOBAL_H
class object_payload;
class pending_frame;
class Communicator {
private:
map<string,object_payload*> local_objects;
map<string,pending_frame*> remote_tasks;
bool listening;
public:
Communicator();
void stop_listening();
void add_to_remote_tasks(string name, pending_frame* pfr);
void listen();
void distributed_release(string task_name);
};
extern Communicator communicator;
#endif
global.cpp
#include "global.h"
class Communicator {
private:
map<string,object_payload*> local_objects;
map<string,pending_frame*> remote_tasks;
bool listening;
public:
Communicator(){
// implementation
}
void stop_listening(){
// implementation
}
void add_to_remote_tasks(string name, pending_frame* pfr){
// implementation
}
void listen(){
// implementation
}
void distributed_release(string task_name){
// implementation
}
};
Communicator communicator;
Does anyone know why this would be giving this error? The .cpp includes the header. I have other .cpp files that also include the header, but with the guard I don't see why that would matter.
Thanks for any help on this, much appreciated.
EDIT: Also, my runner.cpp file (with main) includes global.h in order to access the communicator global object.
You must have only one definition of a class. Currently you get one from #include and another in the file.
You shall not repeat the class itself, just implement the functions out of class, like
Communicator::Communicator(){
// implementation
}
That's not how you do the separation. The class (i.e. the declaration) goes into the header; the CPP file should have method implementations, like this:
Communicator::Communicator() {
...
}
void Communicator::stop_listening() {
...
}
and so on. Note the Communicator:: part of the fully qualified name: this is what tells the compiler that the function that you are defining belongs to the Communicator class.
In your cpp file you only need to define the functions that were declared but not defined in the header and scope them to your class:
Communicator::Communicator(){
// implementation
}
void Communicator::stop_listening(){
// implementation
}
void Communicator::add_to_remote_tasks(string name, pending_frame* pfr){
// implementation
}
void Communicator::listen(){
// implementation
}
void Communicator::distributed_release(string task_name){
// implementation
}
You define the class Communicator in the header file, and then try to add to it in the .cpp file. You can't do that in C++ - all the parts of the class definition must be in the same place.
Your header file should probably contain all the member definitions and function declarations, and your .cpp should proceed to define the member functions like:
void Communicator::stop_listening() { ... }
I currently have a project with 3 files.
One DBheader.h header file that includes:
Class declarations (with their smaller member function definitions)
A DBdefinitions.cpp file with:
Larger member function definitions for the classes in DBheader.h
and finally a DBmain.cpp file that contains:
Main code
Some large (non-memeber) functions that use the classes defined in DBheader.h
I would preferably like to move these functions somewhere to make my DBmain.cpp file less cluttered. Should/could I move them to the DBdefinition.cpp file or do I need to create a new separate .cpp file for non-member functions?
Here's a rough of what my code looks like if the above is unclear.
//DBheader.h
//libraries..
class course{
//member data..
void printinfo();
}
-
//DBdefinitions.cpp
#include "DBheader.h"
void course::printinfo(){/*do stuff*/}
-
//DBmain.cpp
#include "DBheader.h"
typedef map<int,course> record;
void fileinput(record &map);
int main(){
//stuff
}
void fileinput(record &map){
//lots of code
}
You should organize free functions that are part of the public interface in a similar fashion you used for the class definition: a header with the declaration and an implementation file with the implementations.
If they are particular to a specific translation unit, keep them in that implementation file.
All free functions should be declared inside a namespace (named for the public ones, anonymous for "private" free functions).
This question already has answers here:
Is it possible to avoid repeating the class name in the implementation file?
(8 answers)
Closed 6 years ago.
If in C++ I have a class longUnderstandableName. For that class I have a header file containing its method declaration. In the source file for the class, I have to write longUnderstandableName::MethodA, longUnderstandableName::MethodB and so on, everywhere.
Can I somehow make use of namespaces or something else so I can just write MethodA and MethodB, in the class source file, and only there?
typedef longUnderstandableName sn;
Then you can define the methods as
void sn::MethodA() {}
void sn::MethodB() {}
and use them as
sn::MethodA();
sn::MethodB();
This only works if longUnderstandableName is the name of a class. It works even if the class is deeply embedded in some other namespace.
If longUnderstandableName is the name of a namespace, then in the namespace (or source file) where you want to use the methods, you can write
using namespace longUnderstandableName;
and then call methods like
MethodA();
MethodB();
You should be careful not to use a using namespace foo; in header files, because then it pollutes every .cpp file that we #include the header file into, however using a using namespace foo; at the top of a .cpp file is definitely allowed and encouraged.
Inside the methods of the classes, you can use the name without qualification, anyway: just drop the longUnderstandableName:: prefix.
In functions inside the class source file that are not methods, I suggest to introduce file-scope static inline functions, like so:
inline type MethodA(type param){
return longUnderstandableName::MethodA(param);
}
Then you can call MethodA unqualified; due to the inline nature, this likely won't cost any runtime overhead.
I'm not sure I'd recommend it, but you could use a macro like:
#define sn LongUnderstandableName
void sn::MethodA(parameters) { ... }
int sn::MethodB(parameters) { ... }
and so on. One of the bad points of macros is that they don't respect scope, but in this case, the scope you (apparently) want is the source file, which happens to correspond (pretty closely) with the scope of a macro.
Well, yes, once you understand namespaces.
Instead of naming your class MyBonnieLiesOverTheOcean, instead set up the following:
namespace My { namespace Bonnie { namespace LiesOverThe {
class Ocean { ... };
} } }
Now, when defining your methods, you put the same namespaces around the whole file, and you write:
Ocean::SomeMethod() ...
When using the class from outside all the namespaces, it's:
My::Bonnie::LiesOverThe::Ocean
If you need to reference a lot of things from some other namespace in some source file, you can use the 'use' directive to ditch the prefixes.