Boost logo

Boost :

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

> - 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).

Boost list run by bdawes at, gregod at, cpdaniel at, john at