Hi Jody, --- Jody Hagins <jody-boost-011304@atdesk.com> wrote: <snip>
The standard multicast socket options are implemented in the asio::ipv4::multicast namespace. They are:
There are some other (not so standard, and ipv6) ones, but that should do for now.
Let me know if you happen to need something else, because they're easy enough to add. <snip>
I actually played with a lib implementation using templates. Ended up templatizing on const builtins with values set to the "actual" value from the system header. It's a bit ugly in the implementation, but the usage is quite nice, and a bit more readble. It's is, at least, possibly to do all your template stuff (like socket options and such) in such a manner, without including the system headers directly.
Interesting ideas. I may have to call on your experience in this when I get to doing the changes. I'm most worried about things like ipv4::address, which contains an in_addr structure. <snip>
While I've been extremely busy, I did try to read the docs. I'm concerned about all the bind() calls. I can live with it the first time, but it looks like I have to rebind after each operation. This can be quite costly. Maybe I'm missing something...
Basically the handler is just a function object. The boost::bind calls are convenient, for sure, but if you're concerned with performance you can define your own function object that simply forwards the callback like so: class my_handler { public: explicit my_handler(my_class* p) : p_(p) {} void operator()(const asio::error& e) { p_->handle_event(e); } private: my_class* p_; }; Having said that, I've been quite impressed with how well boost::bind is optimised by MSVC for example, so I haven't found it an issue in practice. Cheers, Chris