-
Notifications
You must be signed in to change notification settings - Fork 287
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
Add World::hasSkeleton() #1050
Add World::hasSkeleton() #1050
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a missing const
dart/simulation/World.hpp
Outdated
@@ -149,6 +149,9 @@ class World : public virtual common::Subject | |||
/// pointers to them, in case you want to recycle them | |||
std::set<dynamics::SkeletonPtr> removeAllSkeletons(); | |||
|
|||
/// Returns wether this World contains a Skeleton. | |||
bool hasSkeleton(const dynamics::SkeletonPtr& skeleton); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This member function should be const-qualified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, if possible, it would be nice to accept a const dynamics::ConstSkeletonPtr&
, but I know that sometimes the STL doesn't like to perform comparisons between std::shared_ptr<const T>
and std::shared_ptr<T>
objects, so maybe it would be more trouble than it's worth.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, would it be better to take just a const raw pointer as a workaround? Or having both for SkeletonPtr
and ConstSkeletonPtr
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The compiler can implicitly cast a SkeletonPtr
to a ConstSkeletonPtr
, no problem. I'm just not sure off the top of my head if
return std::find(mSkeletons.begin(), mSkeletons.end(), skeleton)
!= mSkeletons.end();
will compile when skeleton
is a ConstSkeletonPtr
, since the compiler might want to cast skeleton
from ConstSkeletonPtr
to SkeletonPtr
, which is not allowed.
I think if the compiler gives us any trouble with the ConstSkeletonPtr
argument, we could use std::find_if
and pass in our own unary predicate that casts each entry to a ConstSkeletonPtr
before comparing it to skeleton
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems ConstSkeletonPtr
works without any troubles in the simple test. Let's merge this as it is and revisit if it turns out this is problematic. 😁
Codecov Report
@@ Coverage Diff @@
## release-6.5 #1050 +/- ##
===============================================
+ Coverage 56.58% 56.59% +<.01%
===============================================
Files 314 314
Lines 24312 24315 +3
===============================================
+ Hits 13758 13761 +3
Misses 10554 10554
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As long as it's compiling, there won't be any issues. I just wasn't sure how the compiler would handle the casting.
Great! Thanks! |
World::hasSkeleton
takesSkeleton
as a shared pointer sinceSkeleton
is enforced to be created as a shared pointer by callingSkeleton::create()
.Before creating a pull request
clang-format
Before merging a pull request
CHANGELOG.md