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

Kenneth Adam Miller kennethadammiller at gmail.com
Wed Jan 15 18:01:12 CET 2014


Heck yeah, I want something that handles the type information for me! I am
doing all that in C++ anyway.
On Jan 15, 2014 7:23 AM, "Lindley French" <lindleyf at gmail.com> wrote:

> Allow me to clarify: the variadic template syntax with the blocking option
> would look like:
>
> // Sender
> socket.send<BLOCKING>("Hello",5,8.4,"Have a nice day");
>
>
> On Wed, Jan 15, 2014 at 8:19 AM, Lindley French <lindleyf at gmail.com>wrote:
>
>> 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.
>>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140115/2b8f2c6c/attachment.htm>


More information about the zeromq-dev mailing list