views:

100

answers:

4

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, 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

+4  A: 

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.

sepp2k
Yeah, you are right, at least for this initial design it seems that I can make most of functions private and just call them from within the template function, I guess I will programm more and see the need for deeper templates
Jonathan
+2  A: 

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.

R Samuel Klatchko
Hmm, I would like to use it basically on implementation.so I guess this is a good design, I use the easyness of templates but don't share my project without permission.But I guess that everytime I will hand over an include file for other software, I will have to copy and edit the headerfile to not show the source right? or there is other way around this?
Jonathan
If your templates are not part of the interface, you should not even have to provide that header to users. If you do need to provide your template headers, then you need to refactor your header files so that the interface header files do not need the implementation header files (and if that is not possible, then the the templates are not really implementation but are part of the interface).
R Samuel Klatchko
A: 

I was thinking to static_cast inside the template function and call a private function with the base class... but then I guess I could do it without the template design... But templates saves lots of arguments to functions and stuff like that... what you guys think about this aproach?

what you guys think about templates?

if you are going to create a library to be used by others, and these otehrs shouldn't be able to read your source, what would you guys do?

Jonathan
A: 

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.

Steve314