Boost logo

Boost :

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2006-02-06 21:58:18


On 2/6/06, Giovanni P. Deretta <gpderetta_at_[hidden]> wrote:
> The problem is that a socket is *conceptually* not copyable. Even if you
> have multiple handles to it, they all refer to the same underlying
> stream. Standard streams are not copyable for the same reason. If you
> want different objects to *share* a socket you use a shared_ptr and
> dynamically allocate it.

IMHO it is not true that a socket is *conceptually* not copyable. In
every platform I use copying sockets are a very intuitive operation.
Couldnt a socket be *conceptually* a reference counted resource?
What, IMO, a socket is *not* is a resource that uses dynamic
allocation. There's no point in using new operator to allocate memory
for a socket!

>
> >
> >>Only if you need the lifetime of the object to be dynamic (as the
> >>example does, but it is *not* always the case) you directly allocate it.
> >>Or make it be a member of a class that is itself dynamically allocated.
> >
> >
> > Even making it a member of the class you'll probably need it to be
> > passed along to another class,
> > which is impossible without
> > copy-construction.
> > Which would need the socket (or the class that owns
> > the socket) to be dynamically allocated and its lifetime to be watched
> > (maybe through shared_ptr).
> >
>
> well, you could hold a shared_ptr (with a null deleter) to the socket or
> class that owns it and have its lifetime be watched by weak_pointers.
> This way no dynamic allocation is needed. If you want the lifetime to be
> dynamic, that is "as long as some one has a reference to it", use
> dynamic allocation an shared_ptr.

My point is that it shouldnt be needed to use dynamic allocation to
use a socket. Even if you need to share it.

[snip]

>
> Yes what? Always what? Are you talking about always needing dynamic
> allocation? Definitely not. I've written code that uses asio
> stream_sockets without using dynamic allocation nor moving nor sharing
> ownership.

If you could show me maybe it could explain a lot of what you mean.
Can you show me any code and what is its use case?

> Why not? If you want shared ownership you dynamically allocate, there is
> no way around it. If you want to give up ownership (to move the object a
> long a chain of functions implementing a state machine for example), you
> move it.

I cant see why shared resource ownership must imply dynamic memory
allocation, IMO it only makes sense to use dynamic memory allocation
when the shared resource is memory. But not when it is a socket, or
file or anything else. Using dynamic memory allocation when it is not
really conceptually needed is a cost that, IMHO, doesnt make sense.

> Well, I'm sure asio uses it in lot's of places :) ... if you mean asio
> should use it to implement reference counting of the underlying
> socket_impl, yes, it could do it *if* you decide to make the socket
> copyable (and I think it the wrong choice).

IMO, should be both.

>
> BTW, I might have misunderstood some (or all) of your reply and be
> arguing about the wrong thing. Sorry if it is so :)

I think you got it right. But I'm still not getting how you solve most
of the use cases for asio without relying on dynamic memory allocation
or why you believe it should be needed dynamic memory allocation on
these cases.

> --
> Giovanni P. Deretta

thanks,

--
Felipe Magno de Almeida

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk