Deleted copy constructor creates problems with keeping frames

[LeKristapino]

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]

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