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

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


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


  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.


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.


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)
Disclaimer: This site not officially maintained by Boost Developers