[zeromq-dev] [zmqpp] Proposed interface addition....possibly breaking

[Lindley French]

I have an idea for updating the zmqpp::socket interface. Unfortunately, I
don't think it's compatible with the current interface, so I want to run it
by the list before going down this route.

The zmqpp::socket interface already includes send() and receive() overloads
which take a std::string instead of a zmqpp::message. My idea is to extend
this to arbitrary lists of types supported by zmqpp::message, using
variadic templates. This would allow you to do things like:

// Sender
socket.send("Hello",5,8.4,"Have a nice day");

// Receiver
std::string str1, str2;
int val;
double dval;
socket.receive(str1,val,dval,str2);

So long as the types match up, everything would "just work". And frankly,
matching the types up is already a requirement so that's not adding
anything new.

I've already figured out how to do this in code. The problem is that the
existing send(string) and receive(string) overloads take a second parameter
indicating whether or not to block. This second parameter can't be used
with the variadic template overload, and if the existing overload is
retained, it would be ambiguous. My proposal is to use a function template
parameter, BLOCKING or NONBLOCKING, to communicate this information.

The send(zmqpp::message, bool dont_block) overload would be retained, and
in fact the variadic overloads would eventually end up calling this one.

There is an alternative approach which doesn't break the existing
interface. I don't think it's quite as "cool", but it ought to work: use a
builder pattern instead of variadic templates to construct multipart
messages. I haven't figured out the code yet but the syntax might look
something like:

// Sender
socket.build("Hello")(5,8)(4)("Have a nice day").send();

// Receiver
std::string str1, str2;
int val;
double dval;
socket.receive()(str1)(val)(dval)(str2);

Not quite as elegant or intuitive, but now compatible with the existing
interface.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140115/e890aa76/attachment.htm>