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 < [email protected]> 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" <[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
