-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Chris Cleeland Sent: Wednesday, January 11, 2006 12:47 PM To: boost@lists.boost.org Subject: Re: [boost] Late asio review
[snip]
If you do that, you still get into the situation of having to replicate what is essentially a system interface at a level that is supposed to provide abstractions and a certain measure of system independence, right? I'm not sure that the Right Thing(TM) is to allow direct access to file descriptors or handles, but the fact remains that over the years I've come up with enough time that I've needed to access something platform or system-specific related to sockets that I've needed something like this.
I don't think it makes sense for asio to become a kitchen sink for those sorts of things, but one also shouldn't be forced to break encapsulation or abandon asio because one needs functionality from one of the lower level tools that the asio designers/developers didn't anticipate.
If possible, I'd lean toward the ability to both take advantage of the platform where it makes sense and rely on portable abstractions everywhere else. What if I need to demultiplex file I/O events as well as socket events in a TCP-based echo client? Without the socket handle, I don't know how to use asio sockets for that.