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

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-02-08 07:35:27

Hi Giovanni,

--- "Giovanni P. Deretta" <gpderetta_at_[hidden]> wrote:
<snip>
> In the end asio::socket_ptr<Stream> would look at its pointed
> object and decide if it needs dynamic allocation or not.

I'm happy with such a solution provided that no requirement is
made that any asio class (stream_socket, etc) must support
copying.

But let me ask: why would this need to be part of asio at all?

Consider a hypothetical smart pointer copyable_ptr<T> that works
as follows:

- checks if a type trait is_intrusively_refcounted<T>::value is
  true, and if so is implemented in terms of intrusive_ptr<T>.

- checks if a type trait is_refcounted_value_type<T>::value is
  true, and if so is simply implemented in terms of T.

- otherwise is implemented in terms of shared_ptr<T>.

Then all asio would need to do is implement the type traits
for its own classes as appropriate.

Maybe boost already has such a thing?

> If it does it dynamically allocates it and it is *exactly
> like* a shared_ptr<Strem>, if it does not (all state are
> pointers), it keep the object as internal state and behaves as
> a collection of shared_ptrs to the pointed to objects. BTW, in
> the end you always have dynamic allocation. There is no way
> around it. But it usually it happens inside some C library
> (SSL_CTX for example or win32 SOCKETS) or in the kernel. So
> the point is not preventing dynamic allocation at all, but
> preventing unneeded extra allocation.

But whether allocation occurs inside the kernel or some C
library isn't really relevant, because that memory doesn't give
us a place to store a reference count. The question is whether
the asio public interface should require dynamic allocation
inside asio's own implementation -- and that is something I am
definitely against.

However, as I said, the above smart pointer solution is
something I could live with, since it simply says that if an
asio implementation happens to use dynamic allocation, then it
may as well also support intrusive reference counting.

> This complicates the desing a lot, so I'm not arguing that it
> should be done (in fact i'm strongly in favour of the current
> interface, plus movable sockets), but I think that *if*, after
> some experience with asio, dynamic allocation of sockets is
> really needed *and* it is a real bottleneck, it can be done as
> an optimization (with asio::stream_ptr).

Yep, I agree. (Except for the movable bit :) see other reply.)

Cheers,
Chris