From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-12-22 17:50:01
On Fri, 23 Dec 2005 09:09:41 +1100 (EST)
Christopher Kohlhoff <chris_at_[hidden]> wrote:
> I guess you must be doing some pretty hard-core networking to be
> concerned about this level of detail. Can you describe a use
> case that would make such a feature widely useful? Some hard
> numbers on performance differences would be quite interesting.
Well, you know... I'm looking for the numbers now. I seem to have not
only lost the numbers, but the program as well. If I can't find them,
then maybe I'll just rewrite the test (as close as I can come to
remembering it) on Christmas Day. I should be allowed to do SOMETHING
fun on that day...
> 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.
> From comments, you'll seed that some people prefer header-only
> and others don't.
Right. Wish there were a way to do both...
> It's on my to-do list to investigate a library implementation,
> but this would be an option, not mandatory. The goal of the
> library implementation would be to hide away the system headers.
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.
> However, a few things need to be considered:
>
> - Much of the library is implemented in templates, so it is
> likely that only the lowest level OS wrappers would be in a
> library.
That's OK. The part I don't want included is the OS related junk.
That's where my namespace gets polluted, and that's where funky macros
come from. All your stuff will be nicely wrapped in the boost::asio
namespace.
> - I am very concerned that any compilation firewall technique
> used does not introduce additional memory allocations. I am
> not yet sure about the best way to achieve this. Some
> declaration of system types may be required (albeit in a
> namespace), for example.
Yes, I agree. I still think you can do it without the memory
allocations. Basically, you are wrapping the system level stuff
(anything that needs non-boost headers) in a library, and providing a
think interface (it can even be templates for the most part).
There will be a performance cost for the extra function call.
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...
I'll try to get some time over the next week to review it a bit more,
but this time of year is HECTIC. Kids, XMAS, work deadlines, end of
quarter deadlines, end of year deadlines, etc... etc... I even canceled
my vacation time (went skiing last weekend with the kids, but other than
that, it's all been canceled).