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

[Lindley French]

I've opened a pull request with the fairly conservative and non-breaking
change of a message::add overload taking an arbitrary number of arguments
(representing multiple adds), a message constructor which takes arbitrary
arguments which are then passed to this new add(), and an extract() method
with arbitrary arguments which does the corresponding get()s. Optionally,
you can specify which index to start at for extract using a template
parameter (default 0); so, for instance, a message coming out of a ROUTER
could use extract<1> to ignore the identity frame. (It wasn't possible to
overload get() for multiple parameters without breaking the existing
interface.)

If it's deemed desirable to provide variadic send() and receive() calls,
that can be trivially implemented on top of this pull request.
https://github.com/zeromq/zmqpp/pull/36


On Thu, Jan 16, 2014 at 8:27 AM, Lindley French <lindleyf at gmail.com> wrote:

> In answer to the first question, no, variadic templates support reference
> types.
>
> In answer to putting the variadic templates in the message constructor,
> maybe. That's more or less the way my current code works internally
> anyway....I'll have to think whether it makes sense to expose that. One big
> plus of doing it that way is it won't break the existing interface after
> all.
>
> To the Receiver idea, I think the easiest approach is to provide a
> variadic extract() function on the message class, if we're going to do
> things on that level. (I would call it get(), but again, that would break
> the existing interface.)
>
>
> On Thu, Jan 16, 2014 at 4:28 AM, Goswin von Brederlow <goswin-v-b at web.de>wrote:
>
>> On Wed, Jan 15, 2014 at 08:19:33AM -0500, Lindley French 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);
>>
>> Wouldn't that have to be
>>
>>     socket.receive()(str1)(&val)(&dval)(str2);
>>
>>
>> > Not quite as elegant or intuitive, but now compatible with the existing
>> > interface.
>>
>> Wouldn't it make more sense to
>>
>> 1) build a message
>>
>> Message m1("Hello",5,8.4,"Have a nice day");
>> Message m2("Hello",5);
>> m2.push(8.4, "Have a nive day");
>>
>> 2) send message
>>
>> socket.send(m1);
>> socket.send(m2, DONTWAIT);
>>
>> 3) Build a reciever (a proxy object collecting the memory for all the
>>    expected message parts)
>>
>> Reciever r(str1, &var);
>> r.push(&dval, str2);
>>
>> 4) Recieve data
>>
>> socket.recv(r);
>>
>> MfG
>>         Goswin
>> _______________________________________________
>> 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/20140123/d349d0cb/attachment.htm>