Using export keyword with templates

As i Understand开发者_如何学Go "export" keyword can be used so that one can expose template classes or function signatures through an header file and abstract the actual implementation in a library file.

Can anyone please provide a practical sample program which shows how to do this?

Are there any disadvantages or important points to note while using this?

EDIT: A follow up question based on the answers. As mentioned in the answers 'export' is deprecated in C++0x and rarely supported by compilers even for C++03x. Given this situation, in what way can one hide actual implementations in lib files and just expose declarations through header files, So that end user can know what are the signatures of the exposed API but not have access to the source code implementing the same?

Attention: This answer is about the historical use of export pre-C++20; C++20 repurposes the keyword for use in modules.

First of all: most compilers (including gcc, Clang and Visual Studio) do not support the export keyword.

It has been implemented in a single front-end: the EDG front-end, and thus only the compilers that use it (Comeau and icc) support this feature. The feedback from the implementers at EDG was extremely simple: it took us time, was extremely complicated, we recommend not to implement it (1), as a consequence it has been dropped in C++0x.

Now, the standard allows (and this is implemented by at least gcc):

• to declare a specialized version of a template function in a header
• to define this specialization in a single source file

and to have it behave as you'd expect from a regular function.

Note: as Johannes points out in a comment, if a full specialization of a function is defined in a header, it must be marked as inline otherwise the linker will complains.

EDIT:

(1) Finally found my reference Why can't we afford export (PDF) by Tom Plum, reviewed by Steve Adamczyk, John Spicer, and Daveed Vandevoorde of Edison Design Group who originally implemented it in the EDG front end.

Export has been removed from the C++ standard. Do not use it.

It's difficult to provide a sample program because almost no compilers support export. g++ will report a warning saying that it's not supported, and IIRC it doesn't even compile in Visual Studio. Moreover, export is deprecated in C++0x, meaning that it's unlikely that future compilers will support it at all.

For a discussion of how to use export in the few compiles that do support it (namely Comeau C++), check out this link which also goes into why export is hard to implement.

And apologies if this comes across as a major anti-export rant. I promise that I don't hate export! It's just not widely supported and you can't really rely on it as a programmer.

The reasons many compiler vendors did not support it is that even when it works it does not do so the way programmers would expect.

The best article I found on the issues is here:

http://msmvps.com/blogs/vandooren/archive/2008/09/24/c-keyword-of-the-day-export.aspx

You are better off instantiating your templates.

I read an article with the title something like Export is not supported and it wouldn't do what you want anyway.

The only way to do what you want is to fully specialize as has been said. But more than that, if you can't see the source code of a library then you can't compile it. This means you cannot accept dynamic memory from it since there is no guarantee you will use the matching delete to their new. For example, if my code is debug and the library is release the deleter will not match the new. You could use shared_ptr and provide a deleter, but that's TR1 and does not have export.

C++11 now has 'extern templates' which are already well supported by modern compilers.

The export keyword is supported in C++20 and is used with the modules language feature (https://en.cppreference.com/w/cpp/language/modules).