[Home]BoostSocket/SocketBaseConcept

BOOST WIKI | BoostSocket | RecentChanges | Preferences | Page List | Links List

Difference (from prior major revision) (no other diffs)

Changed: 1,67c1,86

SocketBase? concept




Provide a full function, platform neutral socket interface.

* DefaultConstructible?
* 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

Michel




Ok, assignable has gone. How should an accept return it's socket? Is a dynamically allocated return value going to present a performance issue?

Hugo




# 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.

Michel



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&)

Hugo




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:
* DefaultConstructible?
* void reset(socket_type socket = socket_type()); // closes any open socket and transfers ownership socket to this socket base.
and maybe for completness.
* socket_type release(); // releases ownership socket and leaves socket_base invalid.


Michel




Looks good. Changed above.

SocketBase? concept

Provide a full function, platform neutral socket interface.


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

Michel


Ok, assignable has gone. How should an accept return it's socket? Is a dynamically allocated return value going to present a performance issue?

Hugo


  1. As an std::auto_ptr<socket_base>. (My assumption is that the heap allocation call is neglible compared to a socket call)
  2. 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)
  3. As a raw socket_type? (User would be responsible for wrapping it in an RAII object like socket_base)
  4. 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.

Michel


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&)

Hugo


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.

Michel


Looks good. Changed above.


BOOST WIKI | BoostSocket | RecentChanges | Preferences | Page List | Links List
Edit text of this page | View other revisions
Last edited December 18, 2004 12:25 pm (diff)
Search:
Disclaimer: This site not officially maintained by Boost Developers