Frame creation policy

We need to adress the issue of creating frames in a neat way.

Now, we have a FrameStructure enum, which is stored in Trajectory.

At frame creation, we do a switch(frame_structure), and then go into deciding which kind of frame to construct.

This is not desirable.

I wrote a Frame factory (checkout factory branch, then see the bottom of factory.h, and also the bottom of FrameBase.cpp and FrameIMU.cpp)

It is still unclear to me how to proceed properly. Frame creation happens at least in:

• Problem.createFrame()

The switch statement, and related hard-coded decisions happen at least in:

• Problem.createFrame()
• Problem.getFrameStructureSize()
• Problem.zeroState()

NOTE: A similar discussion exists for Constraints. This will be another issue.

Or rather than factory and switch statement, the Trajectory class could be templated on FrameStructure enum. Then with specialization all the magic related to FrameStructure would happens in Trajectory. For instance the frame creation would take place in TrajectoryBase::addFrame to which we pass the Frame arguments.

Status changed to closed

I see your point @artivis . But this enum FrameStructure will disappear, as will do most enums in wolf.h. See #98 (closed).

In order to follow your argument, we can derive specific FrameXxx classes from FrameBase (as we did with FrameIMU) and template Trajectory based on this.

A second point: addXxx() must be reserved to methods taking a constructed object and adding it to the list. If the object needs to be created, we use createXxx. If it needs to be created and added, we use installXxx(). See #77 (closed) for a discussion on this (not yet agreed on somthing clearly stated).

Your recent sensor_ptr->addCapture() is probably wrong in the name, since it is not doing the addXxx() paradigm.

Ok Ok I see.

However bool SensorBase::addCapture(const CaptureBasePtr capture_ptr); does take a constructed object; which maybe should not be const.

Indeed, it takes a constructed object, this is fine! However, it does not add it to a list, and it calls process().

I'd like to find a name which is not addX(). Any idea? process(CaptureBasePtr c)?

process() makes sense as it was the previous keyword.
As you wish. Maybe it is better that you choose and change it.

Why is this issue closed? The switch with ENUM is still there...

reopened

closed