Skip to content
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

Deleted copy constructor creates problems with keeping frames #638

Open
LeKristapino opened this issue Apr 26, 2024 · 1 comment
Open

Deleted copy constructor creates problems with keeping frames #638

LeKristapino opened this issue Apr 26, 2024 · 1 comment

Comments

@LeKristapino
Copy link

LeKristapino commented Apr 26, 2024

We have a case where we'd like to hold on to zmq::message_t objects and hold them in a vector. This functionality also makes sense when, for example, building a custom load balancer to keep the routing_ids for messages. Because of the deleted copy constructor we've now resorted to holding them in string. Allowing copy constructor for this kind of scenario seems like it would make sense.

In our case

We have

Class A {
...
private:
  std::vector<zmq::message_t> prefixFrames_;
}

And we get error :
zmq::message_t static assertion failed: result type must be constructible from value type of input range

It can be fixed by adding in zmq.hpp

// copy constructor for message_t using zmq_msg_copy
        message_t(const message_t& rhs) {
            int rc = zmq_msg_init(&msg);
            if (rc != 0)
                throw error_t();
            rc = zmq_msg_copy(&msg, const_cast<zmq_msg_t*>(rhs.handle()));
            if (rc != 0)
                throw error_t();
        }

and deleting

//  Disable implicit message copying, so that users won't use shared
//  messages (less efficient) without being aware of the fact.
message_t(const message_t&) ZMQ_DELETED_FUNCTION;

Even though it is less efficient, it doesn't seem like it makes sense to outright delete this functionality. Or maybe there is some alternative solution that is a better fit for our use case?

@gummif
Copy link
Member

gummif commented Aug 12, 2024

Can you give a short example where this fails? Deleting the copy constructor should be fine since e.g. std::vector<std::unique_ptr<int>> works fine godbolt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants