What's the thoughts on allowing simple constructor/method definitions in header files in C++. Some classes I am creating are simple data objects that compose another object say, so they need there own constructor and get/set methods. However these are usually < 3-4 lines each with the constructors using init lists. Is it OK to just have .h for these classes.?
UPDATE:: What about where to store .h files, in a seperate directory from the cpp files?
I'd vote for only putting declarations in your header file. This will make the header file more clean (no implementation cluttering your view). The user can look upon the header file to view the interface, without being confronted with irrelevant implementation details.
Putting definitions (as opposed to declarations) in your header file can also cause linker errors (as mentioned by Captain Comic). Maybe not currently, but surely when you expand your code.
Besides, explicitly separating declaration from definition (lets forget templates and inline functions here) also works towards a more "perfect" model. The code will be completely modularized in separate source files. From my personal experiences this takes time and care, but is consistent and avoids linker errors etc.
Surely, if you're writing a quick application nobody else is going to see...nobody is there to criticize ;)
Go for it.
If you want a better response, elaborate on your problems, post code, etc.
I put .h files in the same directory as the .cpp files. They are coupled anyway, so why split them up?!
It's much easier for the IDE to locate the matching file when you want to jump between declaration (in foo.h) and definition (in foo.cpp).
Only for external headers, that is those headers that are used by external projects, I might create a separate folder.
One important thing you have to bear in mind is that it is the .cpp files that are compiled, not header files. So design carefully who will include you headers, otherwise you'll get linker errors.
I asked my professor this same question a few hours ago, when he advocated putting a few getters in a .h file, which was foreign to me as a C programmer.
He said that one purpose of the .h file was to give a quick overview of the class. If you've ever programmed in Java, you've probably built or read some huge classes, and locating a specific function can be a pain. A good text editor with folding capabilities or an IDE with an outline view can help you cope with the problem, but that's not always available. A one-line getter/setter or initializing constructor which will not slow a reader down is probably permissible.
Sometimes it all depends on the IDE or the environment in which you are developing the code. Usually
/source-tree
/bin -------> executables or lib or dlls
/h -------> headers
/source -------> source codes
/Makefile -------> The root make file
Now about the code structure, it depends on what you are developing. If some APIs for some data container, which will be used across different modules, It is something like, -
Header Files ------->
//ICoordinate.hpp
template <class T>
class ICoordinate
{
public:
virtual ~ICoordinate() {}
virtual void SetX(T ) = 0;
virtual void SetY(T ) = 0;
virtual T GetX(void) = 0;
};
// Co-ordinate system for ploting decimal points :-)
// class template specialization.
template <>
class ICoordinate<int>
{
public:
virtual ~ICoordinate() {}
void SetX(int );
void SetY(int );
private:
int x,y;
};
Source File --------->
// DecimalCoordinate.cpp
// Implementation for DecimalCoordinate
If you do not have problem with vtable lookup latency, you can always define with some pure virtual methods (just what i did here). There is post regarding the interface declaration.
