Open AlgoryxJosef opened 1 year ago
I think in C++ that would be tricky: the C++ types use the STL containers and so you can't be peeking and poking in memory like you can in C. That said, C++ interoperates with C quite well, and so it would be very simple to wrap the C code in C++. If you have a regular C++ application and there's just this small part where you need to be able to subscribe to arbitrary data, then I would probably just get the C handle from the C++ participant (participant->get_ddsc_entity()
) and take it from there. Indeed, if I were to implement the spec'd dynamic API in C++, that's the route I would take.
We haven't gotten any factory methods for constructing them yet. Those would be pretty straightforward to do, but we're hoping to avoid having to do them because it is so much tedious work and Python does it so much nicer ... That's clearly not a hard no, but I'm pretty sure it is not going to happen anytime soon simply because of having to choose what gets priority. We'd definitely be delighted if someone were to contribute it.
Thank you for that answer, it clears things up for me in terms of the current state of the implementation. While I haven't got the exprience of DDS necessary to undertake such a task (factory helper classes etc), I hope that someone enthusiastic, and with the free time, will come along soon.
All the best!
A set of factory methods (in C/C++) would be crucial in developing a CycloneDDS implementation of REP-2011 for ROS 2, in case that helps to bump up the priority. I don't think I currently have bandwidth to help with implementing the factory methods, but if anyone has the time to, how would one go about writing those methods?
(There currently is a prototype implementation for the REP for FastDDS and protobuf already.)
Pinging @eboasson and @wjwwood for visibility :>
I would guess that after those factory methods are created, issues might surface during implementation, but we can take it one step at a time
For more specificity, the types of interface needed include (minimally):
It would also be nice to have interfaces for:
William might have some more ideas of more features we need 🤔
I would add to that the importance of creating a clear example as well, as this can greatly help developers get going with this.
Notice that I actually closed this issue since my question was answered, but if there is a real interest for this, and this being something that might actually get done, then either this issue can be re-opened and re-named, or a new issue could be created, referencing this discussion from that.
@AlgoryxJosef and @methylDragon
Notice that I actually closed this issue since my question was answered, but if there is a real interest for this, and this being something that might actually get done, then either this issue can be re-opened and re-named, or a new issue could be created, referencing this discussion from that.
I just remembered this. With #1578 merged, I figured this would be a good time to ping you. We (@Splinter1984 mostly) are currently dog-fooding it to dynamically construct an XTypes TypeObject for ROS 2 topics in the Cyclone DDS RMW layer, which will give us the ability to do cyclonedds subscribe T
where T
is some random ROS 2 topic.
!! That is amazing news! Thanks for this!!
Hi, I found the dynsub.c example really helpful. I was wondering how I would go about going the other way? That is, can I create a DynamicData type if I know the layout of a certain message at runtime, but dont know about the message type at compile time?
Some dds implementations have factory methods to construct DynamicData (xtypes?), are there any similar things here? I know dynamic types are easiest in Python, but lets say for arguments sake that I am bound to C.
Best regards Josef