5

I have a question about a code that I have recently took in my hands. I just want to know if in C++ templates paradigm it is correct or useful to do the following inheritance (just 3 classes as an example):

template< class I, class P, class D, unsigned int ID = 0 >
class PathFilter : public Filter< I, P, 1 >
{
...
}

template< class I, class A, unsigned int N = 1 >
class Filter : public Algorithm< I, A >
{
...
}

template< class I, class A >
class Algorithm : public A //This line
{
   ...
}

My question is specifically about the inheritance in the third example. Is it useful to make it so 'generic' and not precise? It is a good choice to compromise understandable code by a more generic code?

I ask firstly because I'm not an expert in C++ templates, but also because I see this code difficult to understand using templates (usually the names of the templates say nothing about its content). Any advice?

Mooing Duck
  • 64,318
  • 19
  • 100
  • 158
Ricardo A Corredor
  • 196
  • 2
  • 10

1 Answers1

2

What you are doing is a mixin class (in particular, your class Algorithm is the one).

As a reference you can consult, for instance, http://en.wikipedia.org/wiki/Mixin or http://en.wikipedia.org/wiki/Composite_pattern.

Indeed you are specifying "certain functionality (specified by A) to be inherited or just reused by a subclass (i.e. Algorithm)". (cit. from the first article)

In other words, you are making yourself (or your user) free to add or change behavior to Algorithm somehow "afterwards". Your real gain is to achieve such a flexibility relying just on the compiler and not on some dynamic-binding-like mechanism (e.g. overriding of virtual functions). Your final class Algorithm<A>, in fact, is built at compile time and it is possibly as efficient as the class you would have obtained writing Algorithm<A> explicitly (i.e. explicitly including the policy A in Algorithm writing it by hand).

EDIT:

I would also suggest to give a look to this wikipedia page about policy based design ( http://en.wikipedia.org/wiki/Policy-based_design ).

There, policies names (your A) appear in a clear form, with clear names, as wisely advised by @full.stack.ex.

Acorbe
  • 8,367
  • 5
  • 37
  • 66
  • 1
    So, if that's what you want, fine. As to readability, true, there's a tradition of naming the template parameters weirdly - I, P, A, etc. But you don't have to :). Give them better names and they may become self-descriptive. – full.stack.ex Oct 16 '12 at 14:32
  • 1
    Thanks for your answer, but I still have a question. I understand the use of a general and abstract definition of some functionalities in a "higher" class. But the main objective of a template is not to generalize parameter types? So what I'm saying at the end is that I can pass almost everything to this higher class and conserve a lower-hierarchy functions. At the end I will have a very restricted set of objects that can inherit (maybe one) the lower functions, am I wrong? It is not an impractical way to define that genericity? – Ricardo A Corredor Oct 16 '12 at 15:10
  • You're right. Surely just a specific set of classes `A` fits in `Algorithm` eventually allowing compilation (those `A` must somehow implement an interface specified by `Algorithm<>`). Now you are using template for design purposes. What you want to do is to write `Algorithm<>` once, and have several algorithms (e.g. `Algorithm`, `Algorithm`,...) just writing small pieces of code more (i.e. classes `RungeKutta`, `Symplectic`...). Somehow you are still general with respect to the type. – Acorbe Oct 16 '12 at 15:14
  • Of course the types `RungeKutta` or `Symplectic` can be defined by you or by a user of your code. Again, the main point is to avoid coupling between `Algorithm` and `A` (which you can achieve through inheritance and virtual functions) at run-time (possibly losing performance). (Of course to my best knowledge). – Acorbe Oct 16 '12 at 15:22
  • Well..thanks again,but I don't understand your example :P.However,in your case we can say that Algorithm implements (inherits) RungeKutta or Symplectic..doesn't matter which one of the classes and of course there I will need a generic function that can be called independently of what I'm using. But again, that means that I can put whatever I want in the top of the hierarchy maybe destroying all the semantic inheritance as for example saying that Algorithm is a 'child' of RungeKutta!It's like saying that the definition of an algorithm come from their examples... That's what I don't understand. – Ricardo A Corredor Oct 16 '12 at 15:44
  • Look at the example in http://en.wikipedia.org/wiki/Policy-based_design . it is not really a matter of inheritance in the standard sense. It is more like compile time modularity. Indeed you should look at `Algorithm` as your RungeKutta class. Because it shared semantics with `Algorithm` you wrote `Algorithm<>` in general. Furthermore the modularity is compile-time solved, so no speed losses.. – Acorbe Oct 16 '12 at 15:46
  • Yes, it is quite similar. But at the end as you see, the classes have a common 'message' method. So they are restricted, and should be described by other inheritance or an interface as you said. But, at the end it seems to me that I don't gain to much than including the classes in the hierarchy. Specially in this case that I present where the patter is applied at the top of the tree ... i think .. – Ricardo A Corredor Oct 16 '12 at 16:05
  • That's right, if there is not interface there is no point (because you can't use it!). You allow for dependencies on `A` at the top of the tree when your class `PathFilter` should be given to a user of yours who needs to specify it a-posteriori (and, moreover, who is not concerned about the whole structure of your code). – Acorbe Oct 16 '12 at 16:21
  • 1
    Thanks once again for your answers.I've looked more in detail what the policy-based design is and it's very interesting as a pattern, but difficult to follow. Here I found a good schematic guide about that http://www.altdevblogaday.com/2011/11/28/policy-based-design-in-c/ helped also with Alexandrescu's book about Modern C++ Programming.Actually, the only thing that I don't see clearly is that every policies should be defined by a general interface as we were talking in the other posts.But well..I'll try to figure out the advantages using this approach in the project I have right now.Buen dia – Ricardo A Corredor Oct 17 '12 at 08:29
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/18155/discussion-between-acorbe-and-ricardo-a-corredor) – Acorbe Oct 17 '12 at 08:39