why socket_t::send accepts a ref of message_t, but recv accepts pointer?

[derekxgl]

socket_t's send and recv signatures are as below. Why send accepts ref, but recv only accepts pointer? also shouldn't send accept const ref instead of ref?

inline bool send (message_t &msg_, int flags_ = 0)
inline bool recv (message_t *msg_, int flags_ = 0)

[grefab]

It's quite common (and AFAIK good practice) to have a pointer type as parameter (not a reference) when you know this parameter's content may be changed by the function. If the parameter's content will not change, usually a const reference is used.

More explanation can be found for example here: https://google.github.io/styleguide/cppguide.html#Reference_Arguments

This conventions would explain the pointer in recv's signature. However, I agree that send should have a const ref. This, though, may be impossible (without a const_cast) if the C interface (i.e. zmq_msg_send, https://github.com/zeromq/cppzmq/blob/master/zmq.hpp#L604) does not handle constness, I haven't checked that.

[derekxgl]

btw, google does not use exceptions in its cppguide :)

[grefab]

Okay, I've checked. The C interface needs a zmq_msg_t*, which conflicts if
send (message_t &msg_, int flags_ = 0)
becomes
send (const message_t &msg_, int flags_ = 0)

However, this can be fixed by const_casting:

before:

inline bool send(message_t& msg_, int flags_ = 0)
{
    int nbytes = zmq_msg_send(&(msg_.msg), ptr, flags_);
    ...
}

after:

inline bool send(const message_t& msg_, int flags_ = 0)
{
    int nbytes = zmq_msg_send(const_cast<zmq_msg_t*>(&(msg_.msg)), ptr, flags_);
    ...
}

I personally find const_casts ugly, but in order to have cppzmq provide a clean interface this may be an appropriate change. Any comments?

[grefab]

Digging deeper: No need for (another) cost_cast. message_t's data() has that already. So I propose send() becomes this:

inline bool send(const message_t& msg_, int flags_ = 0)
{
    int nbytes = zmq_msg_send((zmq_msg_t*) msg_.data(), ptr, flags_);
    if (nbytes >= 0)
        return true;
    if (zmq_errno() == EAGAIN)
        return false;
    throw error_t();
}

[derekxgl]

I'm new to zeromq and its cpp api. Obviously it's wrong/dangerous to accept a const ref but const away to modify it internally.

[grefab]

Yeah, it is. I assumed that sending a message does not modify it, but I am wrong. From the guide:

The zmq_msg_t structure passed to zmq_msg_send() is nullified during the call. If you want to send the same message to multiple sockets you have to copy it using (e.g. using zmq_msg_copy()).

(See http://api.zeromq.org/4-0:zmq-msg-send)

So the const_cast is actually a bad idea. In that case, I'd like to get rid of the reference at all and just keep the pointer signature of send(). That, however, will break backwards compatibility in order to stick to a non-standard convention, so it's not a good idea either.

[derekxgl]

Certainly you can overload socket_t::send with a new one accepting a pointer to message_t and leave the one with message_t ref unchanged to keep it backward compatible.

[szmcdull]

There is a new zmq_send_const API in ZMQ 4.1.4. Please add support for this.

[aytekinar]

I have stumbled upon this thread when I also thought about why they had different signatures. Could you please clarify the need to require send and recv methods to have different signatures, @grefab ? I am not an expert in C++, but yet again, I have read some articles such as this which has fairly valid points against google style guide.

in my point of view, they should both have non-const references. having recv receive message_t as a reference will help have a symmetric set of definitions in both recv and send, except for the corner-case of sending messages based on iterators. In that way, we would be able to use rvalue references for the recv (I am not sure if that helps, at all, but at least we can have a consistent API), too. Another advantage of having references is, in my opinion, to have valid objects, in the sense that, we cannot have uninitialized object references whereas we can just pass uninitialized object pointers to those functions.

what do you think @grefab and @derekxgl ?

[joncage]

I also fell foul of this: http://stackoverflow.com/questions/41893295/why-does-zeromq-req-rep-give-me-an-empty-response-between-c-and-python

[aytekinar]

@joncage, I think your problem is mostly related to confusing/mixing the C API with that of C++.

If you are going to use C++ API (this API), you should try to avoid pointers --- they are not encouraged in modern C++ due to a lot of reasons (unless you need some polymorphism --- and, in this case, you are not using polymorphism on the ZMQ C++ API).

Then, this API already provides you with a handful of data types, i.e., templated classes, that you can use to get rid of the clutter in your C++ application. Specifically, for the very simple example you have provided in SO, you can benefit from iterators and constructors defined for the std::string class. Please check the modified version below:

#include <iostream>
#include <string>

#include <zmq.hpp>

int main(int argc, char* argv[]) {
  constexpr unsigned int port { 5563                                            };
  zmq::context_t  context     {                                                 };
  zmq::socket_t   publisher   { context, zmq::socket_type::rep                  };
  std::string     bindDest    { std::string("tcp://*:") + std::to_string(port)  };
  zmq::message_t  request     {                                                 };

  publisher.bind(bindDest);

  bool notInterrupted = true;
  while (notInterrupted)
  {
      // Wait for a new request to act upon.
      publisher.recv(&request);

      // Turn the incoming message into a string
      std::string requestStr      { (char *) request.data()   };
      std::cout << "Got request: " << requestStr << std::endl;

      // Call the delegate to get a response we can pass back.
      std::string responseString  {  requestStr + " response" };
      std::cout << "Responding with: " << responseString << std::endl;

      // Turn the response string into a message.
      zmq::message_t responseMsg  { responseString.cbegin(),
                                    responseString.cend()     };

      // Pass back our response.
      publisher.send(responseMsg);
  }

  return 0;
}

As you can realize, getting rid of the pointers and C-style character arrays in your code help you write cleaner (easily readable) code with (hopefully) no memory leakage.

Even then, you have the above-mentioned problems due to the inconsistent implementation of the recv and send member functions of socket_t type objects. For me, and for some other people here, they should both have either references to the objects or pointers. However, the API does not allow for it. This discussion is all about it. I hope this makes it more clear for you.

I apologize if I have got you bored by (maybe) explaining something that is already obvious for you (I do not know your experience in C++, and I cannot consider myself as an expert, either).

[joncage]

I must admit I've lived on the edge of the embedded world for a while and I sometimes miss the niceties available with the std classes.

Unfortunately we're limited to the Visual Studio 2008 tool chain which limits some of the niceties (no std::to_string for us I'm afraid). There are a number of improvements in your example that we can however use so thanks very much for that.

One day we'll join the modern world...!

Your suggestion to unify the interface with references would certainly have helped me in avoiding that SO post.

[aytekinar]

Actually I have solved my issue by simply adding

inline bool recv (message_t &msg_, int flags_ = 0)
{ return recv(&msg_, flags_); }

under the definition of recv for the pointer type. I have added this repository as a submodule to my project, too. As a result, I can always fetch the updates from the upstream, and yet, keep my introduced changes on top.

Most likely, you have already thought about this solution, but I still wanted to let you know. It might not be the most efficient (as the object code will increase in size, since the above method is not templated), and thus, this might not be wanted in your embedded solution, either, though.