BOOST WIKI | BoostSocket | RecentChanges | Preferences | Page List | Links List
Provide a full function, platform neutral socket interface.
- explicit socket_base(socket_type socket) - construct from platform socket
- void reset(socket_type socket = socket_type()) - closes any open socket and transfers ownership socket to this socket base.
- socket_type release() - releases ownership socket and leaves socket_base invalid.
- template <typename IoctlOption?> int ioctl(IoctlOption?& option)
- template <typename SocketOption?> int getsockopt(SocketOption?& option)
- template <typename SocketOption?> int setsockopt(const SocketOption?& option)
- template <typename Protocol> SocketError? open(const Protocol& protocol)
- template <class Addr> SocketError? connect(const Addr& address)
- template <class Addr> SocketError? bind(const Addr& address)
- SocketError? listen(int backlog)
- template <class Addr> int accept(socket_base&,Addr& address)
- int recv(void* data, int len)
- int send(const void* data, int len)
- SocketError? shutdown(Direction how=Both)
- SocketError? close()
- bool is_valid() const
- socket_type socket()
- bool operator<(const socket_base& socket) const
- bool operator==(const socket_base& socket) const
- bool operator!=(const socket_base& socket) const
- bool initialise() - platform initialisation hook
- void finalise() - platform finalisation hook
I don't really like the idea of this class to be copyable and assignable. No more than std::fstream or boost::thread. The rationale would be pretty much the same as the one in http://www.boost.org/libs/thread/doc/rationale.html#non-copyable
Ok, assignable has gone. How should an accept return it's socket? Is a dynamically allocated return value going to present a performance issue?
- As an std::auto_ptr<socket_base>. (My assumption is that the heap allocation call is neglible compared to a socket call)
- As an boost::shared_ptr<socket_base> (This would have the advantage that the socket_base implementor could use some other kind of allocation strategy and release strategy internally)
- As a raw socket_type? (User would be responsible for wrapping it in an RAII object like socket_base)
- Or socket_type could be defined to have semantics of auto_ptr ie ownership is transferred).
I would prefer solutions in listed order?
What about CopyConstructible??
The socket_base class should also call close or closesocket internally in it's destructor if a socket has been allocated.
My only problem with std::auto_ptr<socket_base> is how to return a socket and an error indication from accept.
Would the following signature be ok? It is my understanding that auto_ptr could not be used as part of std::pair return.
int accept(std::auto_ptr<socket_base>&, Address&)
Ok what about?
SocketError? accept(socket_base&, Address&);
and leave the memory managment up to the user of this class.
This would mean that socket_base need:
and maybe for completness.
- void reset(socket_type socket = socket_type()); // closes any open socket and transfers ownership socket to this socket base.
- socket_type release(); // releases ownership socket and leaves socket_base invalid.
Looks good. Changed above.
Disclaimer: This site not officially maintained by Boost Developers