Question : Using SensorType (and such) in SensorFactory ?

The SensorType enum is defined in the header wolf.h and used as a member of the base class SensorBase.

Why wouldn't we use it as the std::map key of the SensorFactory as well ?? I do remember a discussion about not centralizing things but looks like it is already the case in wolf.h. If tomorrow I want to add (e.g.) an omnidirectional camera then I will have to add this sensor type in the aforementioned enum anyway.

Moreover making it a scoped enum would enable a namespace-like grouping of the enumerated sensor types :

typedef class enum SensorType
{
ODOM_2D,
ODOM_3D,
...
}

auto my_sensor_type = SensorType::ODOM_2D;

Yes. We'll do this, but not yet. Once we decide it, it's not that difficult.

It's the same case for all derived types. And it involves automatic creation, therefore probably (or possibly) Factories for all derived objects.

In NodeBase, there is a 'type' which is a string, and a 'class' which is another string. These are thought to do the job of 'keys' for eventual maps in eventual factories, whenever necessary. There is also a 'name' which is again a string, suposed to be unique per object, which might be used to bind things together (by now, processors to sensors), as well as an id(), which is also a unique 'unsigned int' that can also act as a key.

Then, the sensorType and other xxxType enums will disappear.

But I have too many open fronts to open this one now.

I'll will give it a shot with an example (let's say SensorType).

Mentioned in issue #109 (closed)

I completely removed SensorType, ProcessorType, LandmarkType and FeatureType from the project.

There still remain FrameType and ConstraintType, which are used in switch - case statements, and was more difficult to do. They will have to be removed too.

Closing this. Continuing in #112 (closed)

Status changed to closed