-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decide on the guidelines for the type of vectors to be used when defining an interface #95
Comments
Right now in the code, we have two approaches:
For the first solution we have:
For the second solution, we have:
If I have to decide when to use one with respect to the other, I guess that I would distinguish the following two cases:
For the first, I would go for @GiulioRomualdi @prashanthr05 what do you think? |
I am totally in line with this. I have a question regarding the
Is there any significant distinction between |
See https://eigen.tuxfamily.org/dox/TopicFunctionTakingEigenTypes.html. More specifically, if you set as input parameter an |
I would like to keep the interface My personal idea is:
For point 5, I would add some template capability (I don't know how and what) to avoid to do this foo(std::string, GenericContainer::Vector, GenericContainerVectorResizeMode) It would be nice to have foo(std::string, GenericContainer::Vector) and then the |
I thought about this. I later realized that the issue here would be that the choice of being resizable or not would be done by the developer, and not by the user. This may be undesirable, since the user may use fixed-size vectors with methods that have been conceived by the developer to work with resizable arrays. Right now this is possible, and eventually, a runtime error is thrown if there is an attempt of resizing the vector, but otherwise it works fine. Instead, if we set this property from template, it would be a strong requirement already a compilation time. Notice that right now the interfaces using a
The resize mode is added to the template methods that do the conversion to a So, the real problem is that it is not possible to convert a random vector to a |
This should be solved by #102. After this, the code that was like void foo(const GenericContainer::Vector<double>& input); can be turned in void foo(const GenericContainer::Vector<const double>::Ref input); while void foo(GenericContainer::Vector<double>& input); will become void foo(GenericContainer::Vector<double>::Ref input); The advantage of this, it that it can be used with all the vectors supported by Eigen::VectorXd test;
void foo(iDynTree::Span(test.data(), test.size()).subspan(5, 2)) Unfortunately, at the moment, it is not possible to use |
I guess this has been fixed robotology/idyntree#766 |
We are currently using |
This issue is part of a broader discussion initiated with #94
In particular, in case we have to develop an interface which requires a vector as input, we have to decide what to use. We have several possibilities:
eigen
vectors, more specificallyEigen::Ref
GenericContainer::Vector
In this issue, we can share thoughts and find an agreement.
The text was updated successfully, but these errors were encountered: