From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-02-07 07:12:05
--- "Giovanni P. Deretta" <gpderetta_at_[hidden]> wrote:
> Felipe Magno de Almeida wrote:
> > On 2/7/06, Giovanni P. Deretta <gpderetta_at_[hidden]> wrote:
> >>Along side the current non-copyable (but maybe movable)
> >>stream_socket asio could provide a stream_socket_ptr that
> >>would behave as if it were a shared_ptr to a stream_socket
> >>(that is, pointer semantics), but it wouldn't actually
> >>allocate a stream_socket (similar to the way an optional
> >>looks like a pointer but actualy is stack based).
> >
> >
> > It is nice, but it wouldnt need to behave like a pointer,
> > syntactically speaking. It should have the same interface as
> > the proper stream_socket, IMO. Only the copying being
> > different.
> >
>
> Well, it behaves like a (smart) pointer (the last to exit
> closes the door) so it should look like a (smart) pointer. Why
> do you think it should have the same interface of a
> stream_socket? What advantages would give you?
>
> (Btw, technically it would have the same interface, but you
> would call members functions using -> instead of . )
This idea has a couple of issues that I can see:
- It does not allow an implementation to store additional state
inside the socket object directly, so forcing a dynamic
allocation on the implementation.
- It does not address stream layering, as in:
asio::ssl::stream<asio::stream_socket> s;
or
asio::buffered_read_stream<
asio::ssl::stream<asio::stream_socket> > s;
Each layer adds its own state, and the whole lot would need to
be reference counted.
Cheers,
Chris