Re: [boost] [review] Asio formal review.

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-23 01:07:16

Hi Jody,

--- Jody Hagins <jody-boost-011304_at_[hidden]> 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