In a header file for other programm to use, can I only declare the templates?

I was wondering about using or not templates, in other thread I found out that templates must be implement in the header file because of some reasons. Thats ok, my question is if the source will be need if other programm use it? from the logic of the other thread's answer, 开发者_Go百科it seems that even other programm would need the full implementation so the compiler can say if a line can or not use the templated function.

if yes, I guess templates are not a good thing for the developer who wants others to use his library? if no, then we are good and templates will be used.

or if at least there is anyway to save my hard, hours spent, code from others?

(I will use stl vectors and such, but I am asking for my own code... Templates seem to be nice, save you a lot of hardcoded lines or macro abusing, but if others can read your source than it makes almost no sense[lot of sense to open projects xD])

Thanks, Joe

---

If you want users of your library to be able to use your templates, their source code needs to be available to those users.

However you can sometimes design your template classes so that most of the logic happens in non-template classes which don't have the full source code in the headers.

---

It depends on whether your templates are part of your libraries interface or whether they are just part of the implementation.

If they are part of the interface (i.e. perhaps a entry point returns an object of a specific template type), then yes, you need to expose your template definitions to the outside world.

But if the templates are solely part of your implementation, then once you build your library, there is no need to share the template definitions with consumers of your library.

---

You could write the templates as wrappers around non-template (often non-typesafe) code.

Advantages are...

1. The source for the non-template implementation code needn't be distributed.
2. It's a good way to reduce template bloat.

The obvious disadvantages are that you have an extra layer of abstraction and overhead, and non-typesafe implementation code obviously requires some care. I tend to have an abstract 'tool' class defined in the non-template code, specialised in the template wrapper. I call it a tool because methods don't primarily act on the tools state, but on objects passed in as void* parameters. The tool class encapsulates as most type-unsafety issues in a few methods. The template also provides the typesafe wrapper that users actually use, which interfaces to the unsafe code, providing the tool instance and doing typecasts etc.

For example, if I'm implementing a tree data structure, most tree algorithms will be type-unsafe and will see nodes and data items as void* pointers (or perhaps node* and data* pointers with node and data being declared but undefined structs). I'll have an abstract tree-tool-base with pure methods for node creation, disposal and other basic operations, and the wrapper template will basically specialise the tree tool, supplying method implementations that know the precise types of the nodes and data items, and holding an instance of the tool as a class member. To the user, the wrapper is just a typesafe container, same as any other.

BTW - when implementing the template wrapper, watch out for dependent name issues.