Writing a message with a local copy vs a directly passing into write()
adam-lee opened this issue · 7 comments
Should there be a difference in how I pass my data to writer.write() function?
Creating a local copy like below works well:
// make a local copy
auto msg = msg_;
// pass it to write()
writer.write(msg);
// Happy
However, passing a private member variable like below does not work at all:
// directly pass a private member variable to write()
writer.write(msg_);
// Unhappy (nothing goes out on the wire)
Ty!
No, there should be no difference. In fact, I don't think there is any way in which you can distinguish between a local variable and a private member in C++ without relying on undefined behaviour, but in this I might be mistaken.
I found it so strange that I tried to reproduce it with "hello world" (macOS, clang, debug build), but to no avail:
diff --git a/examples/helloworld/publisher.cpp b/examples/helloworld/publisher.cpp
index 5e4c3f80..26115402 100644
--- a/examples/helloworld/publisher.cpp
+++ b/examples/helloworld/publisher.cpp
@@ -22,6 +22,16 @@
using namespace org::eclipse::cyclonedds;
+template<typename T>
+class test {
+public:
+ test(dds::pub::DataWriter<T> wr, T& m) : m_(m) {
+ wr.write(m_);
+ }
+private:
+ HelloWorldData::Msg m_;
+};
+
int main() {
try {
std::cout << "=== [Publisher] Create writer." << std::endl;
@@ -55,7 +65,8 @@ int main() {
/* Write the message. */
std::cout << "=== [Publisher] Write sample." << std::endl;
- writer.write(msg);
+ //writer.write(msg);
+ test(writer, msg);
/* With a normal configuration (see dds::pub::qos::DataWriterQos
* for various different writer configurations), deleting a writer willThat's what you mean, is it not?
Maybe @reicheratwork has an idea, but my first thought would be to double-check your code. Perhaps something weird can happen if you manage to pass a partially initialized sample to write, and if so, then perhaps the copy constructor might happen to turn that into a fully constructed sample. But I am really guessing here.
@eboasson I will see what I can find out here, because like you said, and tried out in the code you showed, there shouldn't be any difference between a private member or a copy thereof.
@adam-lee to make sure we're on the same page here, could you tell me the following:
- what is the version/commit hash of CycloneDDS-CXX that you are using?
- you said that sending the private member "did not work at all", what do you mean with this?
- no sample was received by a reader on the same topic?
- the contents of the sample received did not match your expectations?
- can you give an example of the code that you wrote that replicates this issue?
Meanwhile, I will do some poking at the code and try to replicate your issue.
@eboasson @reicheratwork I appreciate the prompt and thorough responses. As long as this is not a known issue, let me double check my code to make sure if I even saw it right. I will report back soon.
My top commits for CycloneDDS [1] and CXX [2].
My top commits for CycloneDDS [1] and CXX [2].
Looking at your commits:
- the versions of CycloneDDS and CycloneDDS-CXX that you are compiling are not missing any commits relative to their current HEAD that should impact this use case.
So while using the latest version is always a good thing to do when trying to see whether a bug hasn't been fixed yet, this seems to be unlikely in this case
Trying @eboasson's example, I cannot replicate your observations, though...
So, can you give an example of the code that reproduces the issue, and could you tell me what you mean with "not working at all"?
Do you mean not receiving anything, or receiving samples, but they are invalid as indicated through their SampleInfo metadata, or are the samples valid, but is the data contained in them not what you expect?
@reicheratwork Let me provide more details this weekend. If I saw what I saw, I've been also trying to answer your question myself:
Do you mean not receiving anything, or receiving samples, but they are invalid as indicated through their SampleInfo metadata, or are the samples valid, but is the data contained in them not what you expect?
I need another day or two to get back into this. Ty.
I re-tested this scenario, and creating a local copy as I described wasn't the change that got me unblocked originally last week. I can't tell what it was, but it's definitely nothing to do with local copy. Sorry for the noise!
@adam-lee No problem, and thanks for closing the issue!