I very much considered just removing the protected inheritance again,
but it would add unnecessary code duplication.
Take note, the overriding `insert` function bypasses the Wrapper and directly forwards to the wrapped container.
This is somewhat dirty and could be an issue for anyone inheriting from `Task`.
`add` falls back to `insert` for both structures,
but `add` throws exceptions and does not provide a return value.
`insert` provides standard STL container access.
So far, returning false from the processor function, just skipped further traversing the current child (depth-wise).
Now, traversal is completely aborted, even not traversing the remaining siblings of the current child.
Having a single boolean return value, we cannot distinguish both cases.
We need the new behaviour for 8061945c15bea22e8f8899c987bc28e3542885aa.
To move a task instance to another one, it's not sufficient to swap all task members,
but we also need to adapt all back pointers, i.e. me_ and parent_ pointers of children,
to point to the (swapped) task instances.
We need to distinguish two cases for how the interface of a nested serial container is determined:
1. from its children
2. from its (outer) context
As long as the interface is not fully resolved, requiredInterface() returns UNKNOWN.
After pruning, the first/last child's interface is remembered and reported instead.
- to allow solution wrappers (WrappedSolution, SolutionSequence)
to transmit their comment and markers as well
- introduced new SolutionInfo.msg,
which is the info common to solution wrappers and actual SubTrajectories
Reworked cost_queue to correctly sort pointer-like types.
Added unittests for new ValueOrPointeeLess<T> less operator, ordered<T>, and rviz cost ordering.
This is not a good approach.
The same can be achieved by generating targets incrementally.
The better approach, to generate IK solutions incrementally,
has to maintain previous solutions for each target.
Release mode builds previously produced broken solutions with too many entries,
debug build triggered the assert
container.cpp:334: assert(solution.empty())
The standard guarantees std::vector(&&a) leaves a.empty() == true,
so the logic there is fine as long as subsolutions is actually
used for move-construction.