Sign in to follow this  

Question about templatized classes

This topic is 4534 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm implementing a templatized, virtual class in my scripting project. I read on www.cpluplus.com that if you create one of these, both the implementation and the declaration must be in the same file. After replacing my header with a .cpp file, I remembered how old that tutorial was. Is this rule still in effect?

Share this post


Link to post
Share on other sites
Quote:
Original post by Drakkcon
I'm implementing a templatized, virtual class in my scripting project. I read on www.cpluplus.com that if you create one of these, both the implementation and the declaration must be in the same file. After replacing my header with a .cpp file, I remembered how old that tutorial was. Is this rule still in effect?


It is. Note that generally, everything should go in a .h/.hpp file; NOT a .cpp file, since you won't be able to include the cpp.

Share this post


Link to post
Share on other sites
From what I can tell it's not so much a rule as only 1 or 2 compilers support it. It's supposed to be standard, but reasons that are above my head it's incredibly hard to implement properly so many compilers just don't do it.

If I remember this is one of the ones that supports it:

http://www.comeaucomputing.com/tryitout/

Share this post


Link to post
Share on other sites
Yeah the fabled tempate "export" feature has been dubbed a failed experiment in C++ standards/compilers. For production use you pretty much have to put templated and inlined code into header files.

Share this post


Link to post
Share on other sites
The problem with the export keyword is that it just can't be done in the traditional C compilation pipeline. It forces the compiler to either generate the code during the link step, or go digging into another object file.

Share this post


Link to post
Share on other sites
Yes, I kind of understand why it doesn't work, I was just wondering if most compilers had implemented a way around it by now. Thanks for all the replies.

Edit: On second though, I really would like to know exactly why it doesn't work instead of the vague knowledge I have now. Anyone know?

Share this post


Link to post
Share on other sites
Quote:
Original post by Drakkcon
Yes, I kind of understand why it doesn't work, I was just wondering if most compilers had implemented a way around it by now. Thanks for all the replies.

Edit: On second though, I really would like to know exactly why it doesn't work instead of the vague knowledge I have now. Anyone know?


Basically, when a template is used with a new template parameter, the compiler must have access to the source code in order to create a new version of the templatized class catering to that particular type.

Share this post


Link to post
Share on other sites
There are a number of problems that make export very difficult to implement. The first is that dependent names are unbound and looked up at the point of instantiation in the context of the instantiation. In other words, the full source of the template needs to be available at the point of instantiation. So seperate compilation of template code cannot eliminate the dependency of the source code on the template definition, it merely transforms the dependency from depending on the source code in form of a definitions in the translation unit to a form of some kind of object code.

The second problem is that separate compilation doesn't really buy you all that much, since the compiler still needs to load the template definition, so you most likely will not see decreased compilation time; indeed there may be an additional non-obvious dependencies introduced as the compiler attempts to find the template definition. In the worst case scenario, the compiler may have to examine the object code of all intermediate files and reject them all for not having the proper template source. This means that even if a vendor provides seperate compilation, the end user, seeing no advantage to separate compilation, may be less than satisified with the product. This is more of a business complication rather than a technical complication.

A third problem is that some symbols that may have previously had internal linkage or had storage optimized out must then have external linkage so that the template definitions can access the storage. This means that the context of template instantiation expands greatly, which in turn means that subtle cross-translation unit changes in meaning can occur in the generated template code. And then doing Koenig lookup in this kind of mixed context generates a number of difficulties in implementation.

There are probably other problems with implementing export, but those are more than enough by themselves.

Share this post


Link to post
Share on other sites
if you put your implementation in a .cpp file (aka ANY file which isn't in the #include chain of the file currently being compiled) ... then the information contained in that .cpp file would not be available to the compiler when it needs it.

I'm assuming this setup:

template.h
template.cpp

other.h
other.cpp

assuming template is some pureply templated class and other is some non-templated class.

Issue 1:

template.cpp is not really a .cpp in one sense because, there is nothing to compile in it - templates don't get compiled themselves.

Issue 2:

other.cpp needs access to all the information in template.cpp in order to compile, NOT just the information in template.h (like it would need for non-templated classes).


Personally I try to use: .h/.c for C compatible files, .hpp/.cpp for normal C++ files and have been experimenting with using either .hxx or .cxx as the name for the file which holds the template function bodies - ie the file that includes implementation details but must be used like a header file. Currently I'm leaning toward .hxx.

Share this post


Link to post
Share on other sites
Quote:
Original post by Xai
and have been experimenting with using either .hxx or .cxx as the name for the file which holds the template function bodies - ie the file that includes implementation details but must be used like a header file. Currently I'm leaning toward .hxx.

That's an interesting option. Currently we use "Impl.hpp" as a suffix for these files so if your header file is "Vector.hpp" then the implementation would be found in "VectorImpl.hpp". Either will work of course, although inventing new extensions may fool some editors ;)

Share this post


Link to post
Share on other sites
The XXXImpl.hpp system I have heard of before and think is pretty good too ... I had just forgot about it ...

as for the file extensions, yeah it is a problem on a few systems out there, although for the tools I personally use it is just a simple setting to add .hxx to the list of C++ highlighted files.

Share this post


Link to post
Share on other sites

This topic is 4534 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this