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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
