Re: [boost] [asio] Tutorial 7 using strdup, new

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