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

[Charles Remes]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140115/daa4fd1e/attachment.htm>