I have classes that look like this:
Header (.h):
class DatabaseX ; //forward declare
class DeepClass
{
public:
void DeepClass(DatabaseX* db);
void doStuff();
private:
DatabaseX *m_db;
};
Definition (.cpp)
#include "some/path/that/stretches/into/a/rather/deep/structure/DeepClass.h"
#include "another/somewhat/disturbing/long/path/to/somewhere/distant/DatabaseX.h"
void DeepClass::DeepClass(DatabaseX* db):m_db(db){ m_db->open() }
void DeepClass::~DeepClass(){ m_db->close(); delete m_db; }
void DeepClass::doStuff(){ // <complicated stuff here> }
Now I want a test that checks that doStuff() does the right kind of stuff.
So I write my own mock DatabaseX.
But I have a problem, my own mock database lives in the test directory, it has no place in production code, and what's worse, DatabaseX was never written to be inherited and overloaded.
It's a concrete class, and isn't anything like an interface.
So my question is, how do I write a test, with all these hard-coded include paths everywhere?
Do I for example:
create another duplicate file structure that matches the include paths, and put my mock DatabaseX there in this duplicate file structure?
Somehow rewite each cpp file before the compiler accesses it by some indirection magic or other?
Add macros to eat up the paths?
Write a python/perl/bash script to temporarily remove the include paths prior to compiling my tests?
Just include everything, accept the dependencies of DatabaseX, and just compile the real thing, and all it's dependencies and then replace at link time?
Accept defeat; don't write any tests, and bury my head in the sand.
OR ... ?
I should say there are well over a million lines of code, so changing the source code isn't an option.
Is there a very simple way to overcome this nightmare via a nice simple compiler option or other?
(Perhaps it's not relevant but I'm using Qt's QTest & QtCreator. Maybe there is some magical switch that makes all these gruesome paths go away!).
I am using GCC 4.8.5
Related
I have this code for an interface of a class in a header file and its implementation in a separate source file :
First :The Header file "Gradebook.h"
#include <string>
using namespace std;
class Gradebook{
public:
Gradebook(string);
void setCoursename(string);
string getCoursename();
void displayMessage();
private:
string nameofCourse;
};
Second :The implementation "Gradebook.cpp"
#include "stdafx.h"
#include "Gradebook.h"
#include <iostream>
using namespace std;
Gradebook::Gradebook(string name){
setCoursename(name);
}
void Gradebook::setCoursename(string name){
nameofCourse = name;
}
string Gradebook::getCoursename(){
return nameofCourse;
}
void Gradebook::displayMessage(){
cout << "Display message function shows :" << getCoursename() << endl;
}
how can i link these two separate files in order to use only "Gradebook.h" in other project , and hide my implementation from the client-programmer ?
There are several answers. It would help to know why you actually want to hide the implementation. Here's the reasons why you might want to do this I can think of offhand.
Protecting trade secrets: Forget it. To be able to execute your code, the computer has to be able to run it. Effectively you can strip away comments, method names and variable names by compiling the code as a static library, even run an obfuscator over it to obscure the control flow (at the cost of slowing it down by adding unneeded jumps), but in the end the code (or the machine code generated from it) has to stay sort of readable or it couldn't be executed.
Make it easier to use your code: If you have several source files and might add more files, and you want your clients to just be able to drop in one file to get all the newest changes without having to add individual source files, compile it as a static or dynamic library. Then you can hand someone the library plus the headers and they can just use them.
You can also create an "umbrella header" that includes all the other headers. That way, clients can simply add the path to your library's includes folder to their compiler invocation/project file and include the one header, which includes all others. If you add or split up a header, you just change the umbrella to include the new headers and all projects that use it keep working.
Note that using a library will limit your clients: They can't step through your code in the debugger easily, they can't fix and compile stuff easily. If they need your code to run on a new platform, or want to use different optimization settings in the compiler, they can't just recompile it.
On the other hand if you plan to sell your library, you might want to hold on to your sources. Customers who don't care about the security of having the code if you ever go out of business can get a cheaper version of the library without the source code, you can charge them extra if they want any of the other features by making them buy a version for the new platforms that you coded for them, etc.
Prevent clients from accidentally relying on implementation details: You don't really need to do anything for this except split up your code into public and private files. Usually your implementation file is private and your headers are public, but you may have some private headers for internal classes.
Since C++ does not allow defining instance variables or methods that aren't declared in the header's class declaration like other languages do that support categories or class extensions, you may have to resort to the Private Implementation (aka 'pimpl') pattern.
What this usually means is that you declare one class that defines the public API that simply wraps a pointer to the actual class that contains the real implementation and calls through to it. It usually only has one instance variable, pimpl, which is the pointer to the other class. You simply forward-declare the private class using class Foo; and thus your clients' code doesn't know anything about the private class (unless they explicitly peek into the implementation file or private header, e.g. when fixing a bug).
Create a single-file class I mention this last because it is generally a stupid thing to do, but just in theory, you could also move the implementation file's content into the header. Then clients only need to include the header and get all the sources. This has lots of downsides, though, like making code harder to read, slowing down compile times, and requiring the client to deal with duplicate definitions of the class caused by including the file from several .cpp files. In short: Don't do it.
In OOP, you want to break apart a program into multiple classes.
In C#, you would do as such:
namespace a
{
public class ClassA
{
//Methods...that are defined and have code in them.
}
}
and to use that class, you just do "using namespace a;".
Say I want to create a class in C++, and define them, and put code in them.
class ClassA
{
public:
void methodA();
}
ClassA::methodA()
{
//implementation.
}
To access this implementation, you would just use #include "ClassA.h". I fully understand that, and then you have to implement that code again? That seems counterproductive as I like to spread my project over a lot of classes.
So what would be the proper procedure to implement ClassA and not re-implement all it's methods again?
You don't have to reimplement them in each CPP file, the C++ linker takes care of making sure the definitions get matched together.
All you need is:
A header:
#ifndef FOO_H
#define FOO_H
class Foo{
//Junk goes here
};
#endif
A cpp:
#include "foo.h"
//implementations for junk goes here
void Foo::junk(){
}
And then you can include foo.h. Each cpp will be compiled to a .o file. Than, those .o files are handed to the linker which can figure out where definitions are and piece together the code correctly.
C and C++ have a different way of doing things. As long as you have a declaration for a class, method, or external variable the compiler will happily compile and leave off the actual definition of the methods, classes, etc, for link time. This is simplifying things a lot, but basically the compiler will leave a hint to the linker in the object file, saying that the linker needs to insert the address of the method here.
So you just need to include the "ClassA.h" file and you can compile fine.
Because of this you see some different behavior in C and C++ than you would in C#. For example, in C or C++ it's perfectly fine to have two different items (methods, variables, etc) that are named the same in different files as long as neither one is visible outside the file. Whereas in C# you would have to use different namespaces or different names. Note - not that I'm saying this is good practice, it's just possible.
The .h header files contain the class specification. The corresponding .cpp files contain the implementation and are compiled to .o files. During development, you would include .h files to access the APIs provided by the class. During compilation/linking stage, you would include the .o files also along with your source files to form the final binary. You don't need to implement anything again, w.r.t to the class you are using.
I always feel a pain when I switch from C# or python back to C++ and meet the .h and .cpp separation.
So I thought that maybe there is a tool that at pre-compilation step can take header (o file with some special extension) and split it to .h and .cpp?
So if original file like this:
class MyClass
{
public:
void HaHaHa()
{
//some logic
}
}
And a result would be as .h and .cpp files:
//.h
class MyClass
{
public:
void HaHaHa();
}
// .cpp
#include "MyClass.h"
void MyClass::HaHaHa()
{
//some logic
}
Some googling didn't show up the ready to use tools. But I'm pretty sure it is not a new idea and such tools should exist.
P.S. It is known that i.e. Visual Assist X and VIM has tools to handle .h and .cpp separation with less pain. But I'm asking about a possibility to have a code in one files and separate them automatically as a part of build process.
This tool may help you: lazycplusplus [Wayback link because the domain was lost]
Project repo: https://github.com/mjspncr/lzz3
I think you're going about it backwards: you want to write the header
file, without the implementations, before writing the code. What would
be nice is a tool which would read the header file and generate the
outline code for the implementation: with namespaces, nested classes and
such, just the wrappers can be quite verbose. But the closest I've seen
is Rational Rose, which starts with a (highly) annotated ULM diagram,
and generates both the header and the boilerplate of the implementation.
It's a very nice tool—I use it whenever it's available—but
it's a bit pricy for the home user, and probably even for small
corporations.
Under Windows Visual Assist X by Whole Tomato does that sort of thing. Not automated though I don't think.
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.
How do I turn one file with lots of classes to many files with one class per file? (C\C++)
So I have that file with such structure: Some includes and then lots of classes that sometimes call each other:
#include <wchar.h>
#include <stdlib.h>
//...
class PG_1 {
//...
}
class PG_2 {
//...
}
//......
class PG_N {
//...
}
If you're not using revision control (tsk tsk):
Back up your entire project in case you mess up.
Cut and paste each class into its own classname.h and classname.cpp files. Replace classname with the name of the class. Update the include guards.
Add the #include directives that you think are necessary for each class's dependencies.
Delete multiclass.h and multiclass.cpp.
Add the single-class files to your project or makefile. Remove the multi-class files from your project or makefile.
Build the project or makefile.
If it fails to build, fix the problem (e.g. a missing #include) and go to step 6.
Once it builds, run your tests.
If the tests fail, diagnose and fix the problem, and go to step 6.
If you are using a revision control system that supports file-level branching (such as Perforce, or maybe Subversion?), you should take care to preserve the revision history, so that other developers can find old changes:
Do the rest of these steps in a development branch, not the trunk.
For each class name in multiclass.h and multiclass.cpp, integrate multiclass.h and multiclass.cpp into a separate classname.h and classname.cpp for that class.
Submit a changelist containing all of these integrations. This makes N copies of the original file, and they all have a revision history pointing to the original.
Check each new file out for edit.
Remove everything from each new file except the code that is needed for that particular class, and update the include guards.
Add the #include directives that you think are necessary for each class's dependencies.
Check the old multiclass.h and multiclass.cpp out for delete.
Check out the project or makefile for edit.
Add the single-class files to your project or makefile. Remove the multi-class files from your project or makefile.
Build the project or makefile.
If it fails to build, fix the problem (e.g. a missing #include) and go to step 10.
Once it builds, run your tests.
If the tests fail, diagnose and fix the problem, and go to step 10.
Submit the changelist with all of the edits.
If you are using a revision control system that doesn't support file-level branching, then some combination of the two methods should work. Hopefully you get the idea.
How do I turn one file with lots of
classes to many files with one class
per file?
Edit: Something I should mention on refactoring in general. There's no such thing as a big step in refactoring (not unless you want to destroy your code-base). You should always make transactional transformations to the code, with validity checks in between (transactional means they are clearly delimited and can be committed and rolled-back at any point). If you have big steps that means you haven't broken them enough into small steps. Also, each step should do one thing and one thing only. (end edit).
Steps:
back up everything (all affected files)
This means perform a commit in your source-control system. If you don't use any source control, install mercurial before continuing (go ahead, we'll wait ;)) - you can thank me later :D
create new files (.h and .cpp file) for the first class you want to remove, then include the new .h file in your old header (the one with many classes).
move the class declaration in the .h file and the class implementation in the new .cpp file.
remove the declaration / implementation from the old file. At this point compile the code, and copy #include dirrectives from the old files to the new files until everything compiles. At this point you should have your class moved to separate files, and included in the old header file. Do not copy all includes, only enough for your moved class to compile correctly.
compile the code (eventually run the application and make sure everything runs).
perform a commit in your source control system.
remove the included new file from your old (multiple classes) header file and compile. go through the code and include the new file in whatever files you get errors.
repeat the steps 5 and 6.
pick new class, go back to step 1.
Possible mistakes and caveats:
you may be tempted to make other changes to the new code while moving it to new files. Do not make any changes. At the end of a cycle (after step 8) you should have the same code you had before step 1, just in different files. Any changes you make to the code in between the steps will be difficult to separate from the refactoring, difficult to track later and difficult to reverse. It's not worth the hassle, especially when you can make the same changes once the refactoring cycle is completed (with no other problems).
you may be tempted to work on multiple classes at the same time. Don't do that either. If you work in cycles you are always able to revert the code (in your SCM) to versions of the code that worked and you have modular changes. It is also very easy to track changes and check you didn't introduce new bugs if you go one class at a time.
Sidenote: If you use a branching SCM you will be able to work on the tasks in parallel, to interrupt your refactoring (commit everything - let's call this "branch head A"), go back to the code before you started refactoring, make some other changes, commit those (call them "branch head B"), then go back to branch head A, finish your refactoring, then merge A and B and you're in business.
There are several ways to accomplish that.
The most straight forward would be to read the file one line at the time and detect if that line starts a class.
Then start detecting matching braces... you know if you find { +1 and } -1 until you reach zero. Yes, there's more to that, but that's the main part.
Select that block and write it on another file.
On the other hand, IF you're using Visual Studio, would be to create a macro and use the DTE to peruse the FileCodeModel of the currently open file, and create a file for each top level class in that.
Two basic coding style patterns are possible:
Class declarations in headers, member function/static data instantiation in .cpp files.
Class definitions with in-line implementation in headers
Option 2 may lead to code bloat since if you use the class in multiple compilation units you may get multiple copies of the implementation in the final link; it is down to the linker to eradicate this and it may or may not do so - YMMV. It also allows users of the class access to the implementation, which may be undesirable in some cases.
A combination of the two with simple getter/setter functions in-lined and larger code bodies in separate compilation units is an option. Often if I have a constructor that is entirely implemented by the initialiser list, I will include its empty body in-line.
Example for class cExampleClass:
cExampleClass.h
class cExampleClass
{
public:
cExampleClass() ;
~cExampleClass() ;
void memberfn() ;
} ;
cExampleClass.cpp
cExampleClass::cExampleClass()
{
// body
}
cExampleClass::~cExampleClass()
{
// body
}
void cExampleClass::memberfn()
{
// body
}
or in-lined:
cExampleClass.h
class cExampleClass
{
public:
cExampleClass()
{
// body
}
~cExampleClass()
{
// body
}
void memberfn()
{
// body
}
} ;
In both cases any source file that then uses cExampleClass simply includes the cExampleClass.h, and cExampleClass.cpp (if it exists) is separately compiled and linked.
Note that if the class includes static data member variables, these must be instantiated in a separate compilation unit in order for there to be just one common instance. Example:
cExampleClass.h
class cExampleClass
{
public :
static int staticmember ;
} ;
cExampleClass.cpp
int cExampleClass::staticmember = 0xffff ;
Do you know how to do it manually? If you know, writing a program to do the same thing is straightforward.
There might not be an easy way to do this. The problem is you have to get the #includes right, split the code correctly to different header and cpp files, and if your classes have cyclic dependencies among themselves, you have to deal with them correctly, or better, try to resolve those dependencies to make them non-cyclic.
Best suggestion I can give you: first try to do this manually for two or three classes. Then decide what kind of physical class layout you need. Afterwards, try to write a program. Don't try to write a program unless you fully understand what to do.
By the way, how many classes/files do have?
EDIT: To get a better notion of what a good physical class-to-file layout may be, I suggest to read Large Scale C++ Design from John Lakos. Is a little bit outdated, since it contains nothing about precompiled headers, but still useful.
I suggest writing a script (in your favorite scripting language) to extract the class declarations into their own file. If you're not good at scripting languages, you can always write a C++ program to extract the class declarations.
Another possibility may be to use an IDE with refactoring capabilities or a refactoring application. I have never used these, so I can't advise on their capabilities.