Dynamic types based on existing template code

[gao_bolin]

I have a library that has a class Signal<T> whose data type is
templated. The class comes with a whole bunch of functions and objects
to do various processing on the signal.

What I would like to do is a DSignal class that does essentially the
same thing, but whose type is unknown at compile type. Since I have
already this template library with everything I want in it, I would
like to maximally reuse it and minimize overheads. It's the first time
I really sit and think about it and the more I do and the more it looks
like a nightmare.

I essentially see two parts in this process, that are not necessarily
completely distinct: (1), How would this DSignal class be build reusing
Signal<T>, and (2), How to import all goodies that were using Signal<T>
before.

At first, I thought I could save a lot of effort using the C++ build-in
dynamic type checking functionality, but now I realize that I won't go
very far with virtual functions, since declarations thereof should
match. E.g. I would have like to have a bottom-up approach, were the
only thing I would rewrite for DSignal would be accessors like
operator(),but that's just not possible, because the return type varies
for different signal precision.

So it seems that I would have to rewrite, for any function that exists,
an equivalent function taking a DSignal as an input and forking to
various implementation of this function with a given list of
types,using a switch, or a table of function pointers. Not really an
enthusiastic perspective.

For functors, maybe a template class could help, e.g. if I had an
inversion functor for Signal<T>, e.g. Inv()(s), I could have a functor
wrapper like

class Wrapper
{
public:
template < class Functor >
void operator()(cons t DSignal &s, const Functor &f)
{
if (s.getType() == DSignal::DOUBLE ) f(s);
else ...
}
};

if I don't mind writting from now on Wrapper()(s, Inv()). Plus, I
cannot use the same Wrapper class to wrap Functors that have the same
arguments but different return values.

The problem of getting from Signal<T> to DSignal is also not that easy.
At first, I wanted not to have an enum in DSignal that would list all
the currently available types, and somehow use typeid instead, so that
maintenance and extension would be easier, but now I don't think that's
possible. In the same logic, I wanted to use inheritance to add
available types to DSignal -- but now I don't think I can. I would
rather not use a super class with each possible Signal<T> as a member,
because this looks super cumbersome. Union is probably not better. So
maybe some kind of smart pointer who would not be templated but uses a
void* and stores the type somewhere?

Any hint or pointer to hints/pieces of code/libraries addressing this
kind of issue would be highly appreciated.

Thanks

Bolin