|
Boost : |
From: Michel André (michel.andre_at_[hidden])
Date: 2005-04-13 17:04:00
Boris wrote:
> Michel André wrote:
> One problem I see with your design is that you have to implement some
> operations in non-socket classes like connector and acceptor separately, eg.
> close(). To implement close() is easy of course but I hope you get the idea.
> On most operating systems connectors and acceptors will make use of file
> descriptors just like other socket classes. We can reuse code with
> inheritance and just add I/O operations to the few socket classes which
> really do I/O. In the class hierarchy at
> http://www.highscore.de/boost/net/basic.png these classes would be datagram,
> passive and connector. There you can also see that the parent class socket
> provides a close() method which is inherited by all other classes including
> acceptor and connector.
I think we are on the same page basically, but different modelling
tecqniques.
Actually close will only be forwarding to socket::close. Since the
connector will own one or more socket instances, and the acceptor will
have one socket instance. The socket is a facade on the socket api. So
it will be quite easy to handle in my design with some one liners. But
I'm not that fond of deep inheritance hierachies and event thaugt about
having a has-a relationship instead of inheritance to the event_source
as well.
Another slight mishap is that the things you call acceptor and connector
arent acceptors and connectors in the sense of the original pattern
(http://www.cs.wustl.edu/~schmidt/PDF/Acc-Con.pdf or POSA 2) as I
interpret it.
/Michel
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk