Hi I have what is hopefully a quick question. As part of homework I've been asked to write my own template vector class (most of the code is there it just needs to be expanded upon). While I understand HOW it works and WHAT it does I have no idea WHERE to put the code or reference it as I have never seen it in context within a program.
Do I create a new cpp file with all this information in it, or do I just add it in above my main method? If I create a new file (either cpp or h) how do I reference it, with just a #include like normal?
This might seem fairly simple but I've tried creating a new .h file and then including it in my main program but I always get scope definition errors.
Most compilers require you to put all the template code in a header file, rather than a source. This is due to the way template expansion works. You just include that header in whichever files need to use your vector class.
Some things to watch out for when creating a header:
Prevent multiple inclusion. If your compiler supports #pragma once you can put that at the top, otherwise use the #ifndef MY_HEADER_H ....... pattern.
Don't forget to put a semi-colon on the end of your class!!!!
Never put using namespace whatever; in the outer scope of a header (it's okay to use it within block scope such as namespace something { ... } or a function).
Be careful of name conflicts with std::vector if you are calling your class vector - make sure nobody has imported the std namespace prior to including your header.
One point you need to keep in mind is that you should place template declaration and definition together in the header file because of the compilation model of templates.
You can create a header file for the templated vector class and include this header file when you would like to use it in other .h or .cpp files.
You can also put them together inside main, but the previous option is better for you to maintain your code.
Related
I have a class that I need to convert to a template class. For this, I am moving the implementation from class.cpp to class-in.h that will then be included at the end of class.h.
The implementation has a few using ... directives as well as a gflag DEFINE_bool. I need to use these in the class-inl.h file but I am told that they shouldn't be placed in a header file.
The class-inl.h is a header file but it will never be included as a regular header file.
Is there a way I can get rid of using/ gflag in the header file? Can I put the gflag, using statements in a class.cpp?
edit: I meant using declaration example using std::cout
My recommendation is to not put usings into header files if they are only used for implementation. They unnecessarily leak symbols and implementation details. If you define using my_shortcut_for_long_type=...., someone is bound to start using it and code breaks when you decide to change it.
It won't kill you to write std::cout instead of cout. If you want to shorten a long type, place the using into e.g. impl namespace; same goes for what used to be static functions in .cpps. Do not forget to mark them inline if you decide to define them also in the header. using can also be defined inside function scope, use that too.
Definitely do not put using namespace std; or any other namespace into headers files unless that is the purpose of that header.
Refrain from using macros if possible also.
It is generally fine to place using in a header file.
Is there a way I can get rid of using ... in the header file?
Yes: Don't depend on the declaration in the header, then you don't need to declare it. But as I stated, there is generally no need to do get rid of using in a header.
Is there a way I can get rid of ... gflag in the header file?
Define it in a source file instead.
Currently, I am writing a few classes, all of which inherit from a base class and somehow enrich it. All of these classes use templates in order to take different elements as parameters (the classes are all variations of an abstract vector class). So I wrote all of the code in one big .hpp file because I read that splitting the code in .hpp and .cpp would cause linker problems (Splitting templated C++ classes into .hpp/.cpp files--is it possible?) and it wouldn't work.
So I was wondering, since it's not really clean and clear to have everything in a big .hpp file, should I split it and how would I do the splitting the right way in order to keep the code as intact as possible? Should I import the child classes into the base class? Do I have to forward declare all my classes in every .hpp file or not? How would the splitting interact with the templates.
If the code is necessary, I can add it. Just trying to keep it short if it isn't.
As far as splitting the code up, there is a technique for templated code where you can split up the declarations and definitions, at least visually (you'll see why I make that distinction in a moment). So you first start with the header, that will contain just your class and function declarations
Foo.h
template <typename T>
T some_foo(T x); // declaration
#include "Foo.inl"
Then you make a separate file for the implementation. Note that we #include this .inl file in our header, so as far as the compiler is concerned all of the code still exists in the header. Doing it this way is just for human readers, but this way you can split up the actual implementation code into separate files and just include them at the end of the header.
Foo.inl
<template <typename T>
T some_foo(T x) // definition
{
return x + 5;
}
Files:
header.hpp
something1.ipp
something2.ipp
something3.ipp
Content of header.hpp:
#ifndef COMPANY_PROJECT_HEADER_HPP
#define COMPANY_PROJECT_HEADER_HPP 1
#include "something1.ipp"
#include "something2.ipp"
#include "something3.ipp"
#endif
Easy peasy. #include is just a "copy-and-paste" operation so you can do what you like to arrange your files in a pleasing, and easy-to-maintain organisational structure.
All the files are headers, but I've given the "sub-headers" the extension .ipp to distinguish them.
So I wrote all of the code in one big .hpp file because I read that splitting the code in .hpp and .cpp would cause linker problems ... and it wouldn't work.
That only implies that you must not split the definition of the function templates from their declaration (or the definition of member function of a class template from the definition of the template). There is no reason to put the definition of all templates into a single header - which your post seems to imply that you did.
So I was wondering, since it's not really clean and clear to have everything in a big .hpp file, should I split it
Sure.
and how would I do the splitting the right way
Just be sure to keep the definitions of the templates in the same file that declared them - as described in the answers to the linked question. If you think that's messy, then you can put the definitions into another header and include that in the declaring header.
Do I have to forward declare all my classes in every .hpp file or not?
Only in headers that refer to the declarations, but don't need the complete definition.
I am using two stacks to implement a queue class. My header file looks like:
#ifndef _MyQueue_h
#define _MyQueue_h
using namespace std;
template <typename T>
class MyQueue {
public:
MyQueue();
~MyQueue();
void enqueue(T element);
T peek();
void dequeue();
int size();
bool empty();
private:
int count;
stack<T> stk1;
stack<T> stk2;
};
# include "MyQueue.cpp"
# endif
And my cpp (implementation) file looks like:
#include <stack>
#include "MyQueue.h"
using namespace std;
template <typename T>
MyQueue<T>::MyQueue()
{
count = 0;
}
template <typename T>
MyQueue<T>::~ MyQueue()
{
}
template <typename T>
void MyQueue<T>::enqueue(T element)
{
stk1.push(element);
count ++;
}
(other functions omitted).
However, using Xcode 4.5, it keeps saying that my functions (MyQueue, ~MyQueue, enqueue, peek, etc.) are redefined. Can anyone help me to clarify where have I redefined them?
Thank you
You're trying something which I really don't like. It's a pretence.
Remove #include "MyQueue.cpp", replace it with the content of MyQueue.cpp, delete the file MyQueue.cpp. Now everything will work.
You are trying to pretend the template code can be split into header file and implementation file. But because it can't you have to cheat by including the implementation file in the header file. It's less confusing if you don't cheat or pretend and just have one file, the header file, with everything in it.
The precise reason that you get a redefinition is that you are compiling your cpp file, which includes your header file, which includes your cpp file again. So the content of the cpp file gets compiled twice.
In C and C++, #include behaves like a copy and paste.
Everytime you see
#include "file"
it should be treated as if you literally retyped the whole file in that one spot.
So if you compile MyQueue.cpp, the preprocessor will prepend the contents of MyQueue.h,
which itself tacks on a duplicate of MyQueue.cpp evidenced by
#include "MyQueue.cpp"
and then follows the native content of MyQueue.cpp.
So the result of
#include "MyQueue.cpp"
inside MyQueue.h, is the same as if you had written one big file with the contents
of MyQueue.h, MyQueue.cpp and MyQueue.cpp again. (with the include of stack in there as well of course)
That is why the compiler complained about functions getting redefined.
The Duplicate inserted from the
#include "MyQueue.cpp"
might also contain the line
#include "MyQueue.h"
but I think the include guards (ifndef,endif) protected against a recursive expansion since that did
not seem to be an issue.
I would like to point out that putting all the implementation code and declaration code in the same file for templates is not the only solution, as others suggest.
You just have to remember that templates are generated at compile time and include them wherever they are needed. Like Aaron has pointed out, you can even force generate a template for a specific type or function so it's accessible to all units.
In this way, the definition of a function can be embedded in an arbitrary module and the rest of the modules won't complain that a function isn't defined.
I like to declare small templates and template interfaces in header files
and put large implementations in special files that are just glorified headers. You could put some special extension like .tpp .cppt or whatever to remind yourself that it is code you have to include somewhere (which is what I do).
It is a suitable alternative to storing large implementations in header files that must be pasted around just to refer to the type (or function signature). And it works absolutely fine, for years now.
So for example, when I am ready to compile my big program, I might have a file called structures.cpp that I designate to implement lots of small structures I use, as well as instantiate all the templates for my project.
all the other .cpp files in the project need to include "mylib/template_structs.h" in order to create instances of templates and call functions with them. whereas structures.cpp only needs to include "mylib/template_structs.cppt" which in turn may include template_structs.h
or else structures.cpp would have to include that as well first.
If structures.cpp calls all the functions that any other .cpp files would call for that template then we are done, if not, then you'd need the extra step of something like
template class mynamespace::queue<int> ;
to generate all the other definitions the rest of the project's modules would need.
The problem is that, when compiling the cpp file, the cpp file includes the .h file and then the .h file includes the .cpp file. Then you have two copies of the cpp code in the same 'translation unit' at the same time.
But there are a few different solutions to this, it depends what your ultimate goal is.
The simplest, and most flexible solution is simply to remove all the template stuff from the .cpp file and put it into the .h file instead. You might think this is bad design, you've probably been taught to keep declarations and definitions in separate files, but this is how templates are usually implemented. (Welcome to the weird and wonderful world of C++ templates!)
But, perhaps these are to be 'private' templates, only to be used from one .cpp file. In that case, the best thing to do is simply to move everything from the .h file into the .cpp file.
There is a third approach, which doesn't get enough attention in my opinion. First, remove the #include "MyQueue.cpp" from your .h file, and recompile. It's quite possible that will just work for you. However, if your project has multiple .cpp files, you might get linker errors about undefined reference to MyQueue<string> :: MyQueue(). (where string is replaced with whatever you are putting in your queue. These linker errors can be fixed by placing template MyQueue<string>; at the end of the file that has the definitions of the templates (your MyQueue.cpp). This means you have to do this once for each type that you plan to store in your queue, but you might see this as an advantage as it helps you remember which types are supported by your queue.
when you include something it replaces the included file with the code within so when you call
#include "MyQueue.cpp"
it replaces that with the cpp file, then your cpp file redefines it.
Getting rid of the line will fix it.
Thinking Time - Why do you want to split your file anyway?
As the title suggests, the end problem I have is multiple definition linker errors. I have actually fixed the problem, but I haven't fixed the problem in the correct way. Before starting I want to discuss the reasons for splitting a class file into multiple files. I have tried to put all the possible scenarios here - if I missed any, please remind me and I can make changes. Hopefully the following are correct:
Reason 1 To save space:
You have a file containing the declaration of a class with all class members. You place #include guards around this file (or #pragma once) to ensure no conflicts arise if you #include the file in two different header files which are then included in a source file. You compile a separate source file with the implementation of any methods declared in this class, as it offloads many lines of code from your source file, which cleans things up a bit and introduces some order to your program.
Example: As you can see, the below example could be improved by splitting the implementation of the class methods into a different file. (A .cpp file)
// my_class.hpp
#pragma once
class my_class
{
public:
void my_function()
{
// LOTS OF CODE
// CONFUSING TO DEBUG
// LOTS OF CODE
// DISORGANIZED AND DISTRACTING
// LOTS OF CODE
// LOOKS HORRIBLE
// LOTS OF CODE
// VERY MESSY
// LOTS OF CODE
}
// MANY OTHER METHODS
// MEANS VERY LARGE FILE WITH LOTS OF LINES OF CODE
}
Reason 2 To prevent multiple definition linker errors:
Perhaps this is the main reason why you would split implementation from declaration. In the above example, you could move the method body to outside the class. This would make it look much cleaner and structured. However, according to this question, the above example has implicit inline specifiers. Moving the implementation from within the class to outside the class, as in the example below, will cause you linker errors, and so you would either inline everything, or move the function definitions to a .cpp file.
Example: _The example below will cause "multiple definition linker errors" if you do not move the function definition to a .cpp file or specify the function as inline.
// my_class.hpp
void my_class::my_function()
{
// ERROR! MULTIPLE DEFINITION OF my_class::my_function
// This error only occurs if you #include the file containing this code
// in two or more separate source (compiled, .cpp) files.
}
To fix the problem:
//my_class.cpp
void my_class::my_function()
{
// Now in a .cpp file, so no multiple definition error
}
Or:
// my_class.hpp
inline void my_class::my_function()
{
// Specified function as inline, so okay - note: back in header file!
// The very first example has an implicit `inline` specifier
}
Reason 3 You want to save space, again, but this time you are working with a template class:
If we are working with template classes, then we cannot move the implementation to a source file (.cpp file). That's not currently allowed by (I assume) either the standard or by current compilers. Unlike the first example of Reason 2, above, we are allowed to place the implementation in the header file. According to this question the reason is that template class methods also have implied inline specifiers. Is that correct? (It seems to make sense.) But nobody seemed to know on the question I have just referenced!
So, are the two examples below identical?
// some_header_file.hpp
#pragma once
// template class declaration goes here
class some_class
{
// Some code
};
// Example 1: NO INLINE SPECIFIER
template<typename T>
void some_class::class_method()
{
// Some code
}
// Example 2: INLINE specifier used
template<typename T>
inline void some_class::class_method()
{
// Some code
}
If you have a template class header file, which is becoming huge due to all the functions you have, then I believe you are allowed to move the function definitions to another header file (usually a .tpp file?) and then #include file.tpp at the end of your header file containing the class declaration. You must NOT include this file anywhere else, however, hence the .tpp rather than .hpp.
I assume you could also do this with the inline methods of a regular class? Is that allowed also?
Question Time
So I have made some statements above, most of which relate to the structuring of source files. I think everything I said was correct, because I did some basic research and "found out some stuff", but this is a question and so I don't know for sure.
What this boils down to, is how you would organize code within files. I think I have figured out a structure which will always work.
Here is what I have come up with. (This is my class code file organization/structure standard, if you like. Don't know if it will be very useful yet, that's the point of asking.)
1: Declare the class (template or otherwise) in a .hpp file, including all methods, friend functions and data.
2: At the bottom of the .hpp file, #include a .tpp file containing the implementation of any inline methods. Create the .tpp file and ensure all methods are specified to be inline.
3: All other members (non-inline functions, friend functions and static data) should be defined in a .cpp file, which #includes the .hpp file at the top to prevent errors like "class ABC has not been declared". Since everything in this file will have external linkage, the program will link correctly.
Do standards like this exist in industry? Will the standard I came up with work in all cases?
Your three points sound about right. That's the standard way to do things (although I've not seen .tpp extension before, usually it's .inl), although personally I just put inline functions at the bottom of header files rather than in a separate file.
Here is how I arrange my files. I omit the forward declare file for simple classes.
myclass-fwd.h
#pragma once
namespace NS
{
class MyClass;
}
myclass.h
#pragma once
#include "headers-needed-by-header"
#include "myclass-fwd.h"
namespace NS
{
class MyClass
{
..
};
}
myclass.cpp
#include "headers-needed-by-source"
#include "myclass.h"
namespace
{
void LocalFunc();
}
NS::MyClass::...
Replace pragma with header guards according to preference..
The reason for this approach is to reduce header dependencies, which slow down compile times in large projects. If you didn't know, you can forward declare a class to use as a pointer or reference. The full declaration is only needed when you construct, create or use members of the class.
This means another class which uses the class (takes parameters by pointer/reference) only has to include the fwd header in its own header. The full header is then included in the second class's source file. This greatly reduces the amount of unneeded rubbish you get when pulling in a big header, which pulls in another big header, which pulls in another...
The next tip is the unnamed namespace (sometimes called anonymous namespace). This can only appear in a source file and it is like a hidden namespace only visible to that file. You can place local functions, classes etc here which are only used by the the source file. This prevents name clashes if you create something with the same name in two different files. (Two local function F for example, may give linker errors).
The main reason to separate interface from implementation is so that you don't have to recompile all of your code when something in the implementation changes; you only have to recompile the source files that changed.
As for "Declare the class (template or otherwise)", a template is not a class. A template is a pattern for creating classes. More important, though, you define a class or a template in a header. The class definition includes declarations of its member functions, and non-inine member functions are defined in one or more source files. Inline member functions and all template functions should be defined in the header, by whatever combination of direct definitions and #include directives you prefer.
Do standards like this exist in industry?
Yes. Then again, coding standards that are rather different from the ones you expressed can also be found in industry. You are talking about coding standards, after all, and coding standards range from good to bad to ugly.
Will the standard I came up with work in all cases?
Absolutely not. For example,
template <typename T> class Foo {
public:
void some_method (T& arg);
...
};
Here, the definition of class template Foo doesn't know a thing about that template parameter T. What if, for some class template, the definitions of the methods vary depending on the template parameters? Your rule #2 just doesn't work here.
Another example: What if the corresponding source file is huge, a thousand lines long or longer? At times it makes sense to provide the implementation in multiple source files. Some standards go to the extreme of dictating one function per file (personal opinion: Yech!).
At the other extreme of a thousand-plus line long source file is a class that has no source files. The entire implementation is in the header. There's a lot to be said for header-only implementations. If nothing else, it simplifies, sometimes significantly, the linking problem.
http://www.learncpp.com/cpp-tutorial/19-header-files/
It mentions the following as another solution to "forward declaration":
A header file only has to be written once, and it can be included in as many files as needed. This also helps with maintenance by minimizing the number of changes that need to be made if a function prototype ever changes (eg. by adding a new parameter).
But, cannot this also be made with "forward declaration"? Since we are defining the function int add(int x, int y) for example in "add.cpp", and using this function in "main.cpp" by typing:
int add(int x, int y);
?
Thanks.
That is certainly possible. But for a realistically-sized program, there will be a large number of functions that a large number of other files will need to declare. If you put a forward declaration in every file that needs to access another function, you have a multitude of problems:
You've just copy-pasted the same declaration into many different files. If you ever change the function signature, you have to change every place you've pasted its forward declaration.
The forward declaration itself does not naturally tell you what file the actual function is defined in. If you use a sane method of organizing your header files and your source files (for instance, every function defined in a .cpp file is declared in a .h file with the same name), then the place that the function is defined is implied by the place that it is declared.
Your code will be less readable to other programmers, who are very used to using header files for everything (for good reason), even if all you need from a header is one specific function and you could easily forward-declare it yourself.
Header files contain forward declarations - that's what they do. The issue they resolve is when you have a more complex project with multiple source code files.
You could have a library of functions, e.g. matrix.c for matrix operations. Without header files you would have to copy the forward declarations for all the matrix.c functions into all the other source files. You would also have to keep all those copies up to date with any changes to matrix.c.
If you ever change the function in matrix.c, but forget to change its declaration in another file you will not get a compile error. You will probably not get a linker error either. All you will get is a crash or other random behaviour once you run your program.
Having the declarations in a single file, typically matrix.h, that will be used everywhere else removes all these issues.
You can use forward declaration but it doesn't scale well and it's unwieldly if you're using somebody else's code or library.
In general, the header file defines the interface to the code.
Also, think what happens if the function requires some user defined type. Are you going to forward declare that too? That type may regularly change its implementation (keeping it's public interface the same) which would result in having to regularly change all the forward declarations.
The header file solution is far more maintainable (less error prone) and make it far easier to determine exactly what code is being used.
I C and C++ one essentially put all the forward and or external declarations into the header. This then provides a convenient way of including them in the various source files without having to manually include them.
In your case, if you have add defined in add.cpp, you can just provide the external declaration in main.cpp and everything is cool. The header file is there to help you when you have a large number of files that need add declared and don't want to do so for each one.
int add(int x, int y); // forward declaration using function prototype
Can you explain "forward declaration"
more further? What is the problem if
we use it in the main() function?
It's same as #include"add.h". If you know,preprocessor expands the file which you mention in #include, in the .cpp file where you write the #include directive. That means, if you write #include"add.h", you get the same thing, it is as if you doing "forward declaration".
I'm assuming that add.h has this line:
int add(int x, int y);
What are forward declarations in C++?