|
Boost : |
From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-02-09 08:33:40
Hi Giovanni,
--- "Giovanni P. Deretta" <gpderetta_at_[hidden]> wrote:
> Would work but not as you think: the pointed object is not an
> asio asio::*_socket, but a set of object pointed to from the
> private members of asio::*_socket: a pointer to the demuxer, a
> "pointer" to the device (the file descriptor), a pointer to an
> SSL_CTX, a pointer to the buffer etc. If you look at most
> asio sockets, they are nothing more than that (that or I'm
> really wrong here!! :) ).
That may be the case now (i.e. 0.3.6) but it may not be the case
in the future. I certainly can't say it will be the case for all
new stream layers.
Possible non-pointer state that I'm thinking of adding to a
socket includes:
- a flag indicating whether the socket is blocking or not
- flags indicating readiness for read/write for use with
level-trigged demultiplexing
- the protocol object used to open the socket (maybe as part
of adding dual IPv4/IPv6 support)
<snip>
> So to make copyable_ptr a separate lib, it would need formidable
> introspection powers to 'see' inside a asio::*_socket or each
> asio::*_socket should in some way (via trait classes) 'explain' its
> state. Because of this tight coupling i think that *if* such a class
> is really needed it should be part of asio.
I was thinking the "introspection" would just be that the traits
classes would be specialised inside asio. But yeah, I don't see
sufficient reason at this time to add something like this over
just using shared_ptr<> on whatever it is that needs reference
counting (which may not be a socket anyway).
> BTW, when do you plan to release next version of asio?
I want to get the IPv6 support finished first so that I can get
comments on it. Probably a couple of weeks away at least.
Cheers,
Chris
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk