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

Lindley French lindleyf at gmail.com
Wed Jan 15 18:59:21 CET 2014


Well this would actually be against zmqpp---libzmq doesn't have to be
touched on this one---but I'll do it.

It's easy to make blocking the default to minimize the impact on existing
code.


On Wed, Jan 15, 2014 at 12:23 PM, Charles Remes <lists at chuckremes.com>wrote:

> Code up a patch against libzmq and submit it. The C4 process is very
> liberal about what is accepted.
>
> On Jan 15, 2014, at 11:13 AM, Ben Gray <ben at benjamg.com> wrote:
>
> Personally I'd prefer if the template parameters where lower case so
> send<blocking> but otherwise I like the idea.
>
> I'm not sure if it would be better to enable a default of blocking, like
> it is now, so that anyone using send( "hello world" ) will basically have
> nothing to change but then require people who used the boolean before to
> switch to this system or to just require everyone does. But either way this
> would have to bump the major version.
>
>
>
> On 15 January 2014 13:23, 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
>>
>>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> 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/45572113/attachment.htm>


More information about the zeromq-dev mailing list