Splitting templated C++ classes into .hpp/.cpp files--is it possible?

Question

I am getting errors trying to compile a C++ template class which is split between a .hpp and .cpp file:

$ g++ -c -o main.o main.cpp  
$ g++ -c -o stack.o stack.cpp   
$ g++ -o main main.o stack.o  
main.o: In function `main':  
main.cpp:(.text+0xe): undefined reference to 'stack<int>::stack()'  
main.cpp:(.text+0x1c): undefined reference to 'stack<int>::~stack()'  
collect2: ld returned 1 exit status  
make: *** [program] Error 1  

Here is my code:

stack.hpp:

#ifndef _STACK_HPP
#define _STACK_HPP

template <typename Type>
class stack {
    public:
            stack();
            ~stack();
};
#endif

stack.cpp:

#include <iostream>
#include "stack.hpp"

template <typename Type> stack<Type>::stack() {
        std::cerr << "Hello, stack " << this << "!" << std::endl;
}

template <typename Type> stack<Type>::~stack() {
        std::cerr << "Goodbye, stack " << this << "." << std::endl;
}

main.cpp:

#include "stack.hpp"

int main() {
    stack<int> s;

    return 0;
}

ld is of course correct: the symbols aren't in stack.o.

The answer to this question does not help, as I'm already doing as it says.
This one might help, but I don't want to move every single method into the .hpp file—I shouldn't have to, should I?

Is the only reasonable solution to move everything in the .cpp file to the .hpp file, and simply include everything, rather than link in as a standalone object file? That seems awfully ugly! In that case, I might as well revert to my previous state and rename stack.cpp to stack.hpp and be done with it.

Solution 1

It is not possible to write the implementation of a template class in a separate cpp file and compile. All the ways to do so, if anyone claims, are workarounds to mimic the usage of separate cpp file but practically if you intend to write a template class library and distribute it with header and lib files to hide the implementation, it is simply not possible.

To know why, let us look at the compilation process. The header files are never compiled. They are only preprocessed. The preprocessed code is then clubbed with the cpp file which is actually compiled. Now if the compiler has to generate the appropriate memory layout for the object it needs to know the data type of the template class.

Actually it must be understood that template class is not a class at all but a template for a class the declaration and definition of which is generated by the compiler at compile time after getting the information of the data type from the argument. As long as the memory layout cannot be created, the instructions for the method definition cannot be generated. Remember the first argument of the class method is the 'this' operator. All class methods are converted into individual methods with name mangling and the first parameter as the object which it operates on. The 'this' argument is which actually tells about size of the object which incase of template class is unavailable for the compiler unless the user instantiates the object with a valid type argument. In this case if you put the method definitions in a separate cpp file and try to compile it the object file itself will not be generated with the class information. The compilation will not fail, it would generate the object file but it won't generate any code for the template class in the object file. This is the reason why the linker is unable to find the symbols in the object files and the build fails.

Now what is the alternative to hide important implementation details? As we all know the main objective behind separating interface from implementation is hiding implementation details in binary form. This is where you must separate the data structures and algorithms. Your template classes must represent only data structures not the algorithms. This enables you to hide more valuable implementation details in separate non-templatized class libraries, the classes inside which would work on the template classes or just use them to hold data. The template class would actually contain less code to assign, get and set data. Rest of the work would be done by the algorithm classes.

I hope this discussion would be helpful.

Solution 2

It is possible, as long as you know what instantiations you are going to need.

Add the following code at the end of stack.cpp and it'll work :

template class stack<int>;

All non-template methods of stack will be instantiated, and linking step will work fine.

Solution 3

You can do it in this way

// xyz.h
#ifndef _XYZ_
#define _XYZ_

template <typename XYZTYPE>
class XYZ {
  //Class members declaration
};

#include "xyz.cpp"
#endif

//xyz.cpp
#ifdef _XYZ_
//Class definition goes here

#endif

This has been discussed in Daniweb

Also in FAQ but using C++ export keyword.

Solution 4

No, it's not possible. Not without the export keyword, which for all intents and purposes doesn't really exist.

The best you can do is put your function implementations in a ".tcc" or ".tpp" file, and #include the .tcc file at the end of your .hpp file. However this is merely cosmetic; it's still the same as implementing everything in header files. This is simply the price you pay for using templates.

Solution 5

Only if you #include "stack.cpp at the end of stack.hpp. I'd only recommend this approach if the implementation is relatively large, and if you rename the .cpp file to another extension, as to differentiate it from regular code.

View more solutions

Comments

[Sheric]

There's two great workarounds for when you want to really keep your code hidden (in a binary file) or keep it clean. It is needed to reduce generality although in the first situation. It is explained here: stackoverflow.com/questions/495021/…

[Ciro Santilli OurBigBook.com]

Explicit template instantiation is how you can go about reducing compile time of templates: stackoverflow.com/questions/2351148/…

[Stephen Newell]

If you're doing this, you'll want to add #ifndef STACK_CPP (and friends) to your stack.cpp file.

[Pavel Kucherbaev]

Beat me to this suggestion. I too don't prefer this approach for style reasons.

[peterchen]

+1 - even though it doesn't work out very well most of the time (at least, not as often as I wish)

[Benoît]

Your answer is not correct. You can generate code from a template class in a cpp file, given you know what template arguments to use. See my answer for more information.

[Martin York]

You dont need the dummey function: Use 'template stack<int>;' This forces an instanciation of the template into the current compilation unit. Very useful if you define a template but only want a couple of specific implementations in a shared lib.

[Charles Salvia]

True, but this comes with the serious restriction of needing to update the .cpp file and recompile every time a new type is introduced which uses the template, which is probably not what the OP had in mind.

[Mark Ransom]

@Martin: including all of the member functions? That's fantastic. You should add this suggestion to the "hidden C++ features" thread.

[Nemanja Trifunovic]

In practice, most people use a separate cpp file for this - something like stackinstantiations.cpp.

[qwerty9967]

@NemanjaTrifunovic can you give an example of what stackinstantiations.cpp would look like?

[sleepsort]

Actually there are other solutions: codeproject.com/Articles/48575/…

[camino]

@Benoît I got an error error: expected unqualified-id before ‘;’ token template stack<int>; Do you know why? Thanks!

[Benoît]

@camino Can you specify the environment (compiler) and the code you are trying to compile ?

[camino]

@Benoît Happy Thanks giving :) I am using ubuntu and gcc 4.8.1. I copy the code above of exscape, and add "template stack<int>;" at the end of stack.cpp. Thanks.

[Benoît]

@camino: thanks, you too ! Can you show me the full contents of stack.cpp ? First questions that come to mind are : have you included <stack> and have you taken care of namespace std for stack ?

[camino]

@Benoît: my code are same as the codes of "@exscape", the only difference is I add "template stack<int>;" at the end of stack.cpp. #include <iostream> #include "stack.hpp" template <typename Type> stack<Type>::stack() { std::cerr << "Hello, stack " << this << "!" << std::endl; } template <typename Type> stack<Type>::~stack() { std::cerr << "Goodbye, stack " << this << "." << std::endl; } template stack<int>;

[Andrew Larsson]

@LokiAstari I found an article on this in case anyone wants to learn more: cplusplus.com/forum/articles/14272

[Andrew Larsson]

+1 And for people wanting to learn more: cplusplus.com/forum/articles/14272

[Paul Baltescu]

Actually, the correct syntax is template class stack<int>;.

[Benoît]

Thanks Paul. I can't believe this (stupid) mistake of mine had stuck for so long !

[underscore_d]

includeing a cpp file is generally a terrible idea. even if you have a valid reason for this, the file - which is really just a glorified header - should be given an hpp or some different extension (e.g. tpp) to make very clear what's going on, remove confusion around makefiles targeting actual cpp files, etc.

[underscore_d]

The glorified 2nd header being included should at least have an extension other than cpp to avoid confusion with actual source files. Common suggestions include tpp and tcc.

[Abbas]

@underscore_d Could you explain why including a .cpp file is a terrible idea?

[underscore_d]

@Abbas because the extension cpp (or cc, or c, or whatever) indicates that the file is a piece of the implementation, that the resulting translation unit (preprocessor output) is separately compilable, and that the contents of the file are compiled once only. it does not indicate that the file is a reusable part of the interface, to be arbitrarily included anywhere. #includeing an actual cpp file would quickly fill your screen with multiple definition errors, and rightly so. in this case, as there is a reason to #include it, cpp was just the wrong choice of extension.

[Abbas]

@underscore_d So basically it is wrong just to use the .cpp extension for such use. But to use another say .tpp is completely alright, which would serve the same purpose but use a different extension for easier/quicker understanding?

[underscore_d]

@Abbas Yes, cpp/cc/etc must be avoided, but it's a good idea to use something other than hpp - e.g. tpp, tcc, etc. - so you can reuse the rest of the filename and indicate that the tpp file, although it acts like a header, holds the out-of-line implementation of the template declarations in the corresponding hpp. So this post starts with a good premise - separating declarations and definitions to 2 different files, which can be easier to grok/grep or sometimes is required due to circular dependencies IME - but then ends badly by suggesting that the 2nd file have a wrong extension

[underscore_d]

Yes, in such a case, the 2nd file should definitely not be given the extension cpp (or cc or whatever) because that's a stark contrast to its real role. It should instead be given a different extension that indicates it's (A) a header and (B) a header to be included at the bottom of another header. I use tpp for this, which handily can also stand for template implementation (out-of-line definitions). I rambled more about this here: stackoverflow.com/questions/1724036/…

[underscore_d]

This is almost a link-only answer, and that link is dead.

[Xupicor]

"it must be understood that template class is not a class at all" - wasn't it the other way around? Class template is a template. "Template class" is sometimes used in place of "instantiation of a template", and would be an actual class.

[Sheric]

Just for reference, it's not correct to say there's no workarounds! Separating Data Structures from methods is also a bad idea as it is opposed by encapsulation. There's a great workaround that you can use in some situations (I believe most) here: stackoverflow.com/questions/495021/…

[Sharjith N.]

@Xupicor, you are right. Technically "Class Template" is what you write so that you can instantiate a "Template Class" and its corresponding object. However, I believe that in a generic terminology, using both terms interchangeably would not be all that wrong, the syntax for defining the "Class Template" itself begins with the word "template" and not "class".

[Sharjith N.]

@Sheric, I didn't say that there are no workarounds. In fact, all that's available are only workarounds to mimic separation of interface and implementation in case of template classes. None of those workarounds work without instantiating a specific typed template class. That anyway dissolves the whole point of genericity of using class templates. Separating data structures from algorithms is not the same as separating data structures from methods. Data structure classes can very well have methods like constructors, getters and setters.

[rxantos]

I would recommend for this to use .inl extension instead of .cpp one. Most IDE are already configured to use .inl as a C/C++ header. So you keep your declarations on the .h and your implementations on the .inl

[Artorias2718]

The closest thing I just found to making this work is to use a pair of .h/.hpp files, and #include "filename.hpp" at the end of the .h file defining your template class. (below your closing brace for the class definition with the semicolon). This at least structurally separates them filewise, and is allowed because in the end, the compiler copy/pastes your .hpp code over your #include "filename.hpp".

[Ciro Santilli OurBigBook.com]

Explicit template instantiation specific question: stackoverflow.com/questions/2351148/…

[Vassilis]

Could you provide a brief Foo-Bar example? Because algorithms operate on data one way or another, so to fully understand, an example could be helpful.