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

[Lindley French]

FYI, the zmqpp::message_t class already does handle C++ types the "right"
way. My proposal is mostly syntactic sugar on top of that.


On Wed, Jan 15, 2014 at 12:01 PM, Kenneth Adam Miller <
kennethadammiller at gmail.com> wrote:

> 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
>>
>>
> _______________________________________________
> 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/4c373e47/attachment.htm>