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

[Lindley French]

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/20140116/dd06205e/attachment.htm>