Claudio Fantacci

Decide at which level an user can interact/command the class composing a filter

8

The current implementation seems a bit too restrictive. While this has the advantage of reducing implementation mistakes for filters, in some context it seems too restrictive. As a results some...

Implement proper C++ visibility support?

1

Implement C++ visibility support as described [here](https://gcc.gnu.org/wiki/Visibility). This will probably allow us to remove [this Windows-specific CMake instruction](https://github.com/robotology/bayes-filters-lib/blob/master/CMakeLists.txt#L24). An example of this implementation can be found in YARP in [`conf/api.h`](https://github.com/robotology/yarp/blob/master/src/libYARP_conf/include/yarp/conf/api.h.in)...

How shold we implement the state?

1

The possibilities could be three - do not implement the state at all and let the user define it all the time; - implement the state in a "static" way,...

We should check all the interfaces we have and enforce cons-overloading for const-correctness. For esample, see all the `get*` methods of [StateModel.h](https://github.com/robotology/bayes-filters-lib/blob/master/src/BayesFilters/include/BayesFilters/StateModel.h) I don't think we are making huge mistakes,...

Just like `ParticleFilter` has a `ParticleSetInitialization`, should we have one for `Gaussian`/`GaussianMixture`?

In the current implementation the base class is technically `Logger`. Logger should be a class that gets another class and log the result.

After #29, we need to choose proper code-related labels. We can follow and simplify the one used in [robotology/yarp](https://github.com/robotology/yarp/). cc @xEnVrE