Let me know if this helps:

  // dependenciestemplate <T> class pool;class socket;class socket::multi;using std::stringstream;using std::istream;using std::ostream;using std::setw; socket::multi socketmultibuffer; class isocketstream{  string&      buffer;  stringstream stream; public:   socketstream () : buffer (socketmultibuffer.get_input ()) {}  ~socketstream () { socketmultibuffer.release_input (&buffer); }   operator istream& () { return stream; }}; class osocketstream{  string&      buffer;  stringstream stream; public:   osocketstream () : buffer (socketmultibuffer.get_output ()) {}  ~osocketstream () { socketmultibuffer.release_output (&buffer); }   operator ostream& () { return stream; }}; typedef pool <osocketstream> output_stream_pool;typedef pool <isocketstream>  input_stream_pool; output_stream_pool output_streams (20); input_stream_pool  input_streams (20); template <class T, pool <T>& P > class pooled_object{  T& t; public:   pooled_object () : t (P.create ()) {}  ~pooled_object () { P.destroy (t); }   operator T& () { return t; }}; typedef pooled_object <osocketstream, output_streams> pooled_ostream;typedef pooled_object <isocketstream,  input_streams> pooled_istream; class character{  int big, small; public:  void send    () { serialize (pooled_istream ()); }  void receive () { serialize (pooled_ostream ()); } protected:  virtual void serialize (ostream& out)  {    out << setw(10) << big << setw(5) << small;  }   virtual void serialize (istream& in)  {    in >> big >> small;  }}; class player{  int x, y; protected:  virtual void serialize (ostream& out)  {    character::serialize(out);    out << x << y;  }   virtual void serialize (ostream& in)  {    character::serialize(in);    in >> x >> y;  }};  

The pool template manages a pool of type T and allows you to reserve an element for your own use and release it back to the system when you are done. socket is a class that encapsulates socket operations. socketmultibuffer is an instance of a class that adapts the simple socket class to add support for multiple input/output buffers, then encapsulates the combining of the multiple input/output streams them into a single input/output stream for send/receive using the socket class interface. socketmultibuffer manages multiple buffers, which are exposed by the socketmultibuffer.get_input/get_output and socketmultibuffer.release_input/release_output functions.

The isocketstream and osocketstream abstract socketmulti's support for multiple buffers and provide a standard istream/ostream interface by containing a stringstream object and exposing its istream/ostream interface. The stringstream object gets its buffer from the socketmultibuffer class, and leaves the details of combining the multiple streams in socketmultibuffer's implementation. The isocketstream/osocketstream classes should be separate, because the socketmultibuffer class allows a buffer to be either input or output, but not both.

Creating a pool of socket streams is easy now, just use the typedef and instantiate the pool with the initial capacity. I used two pools, one for input and one for output. To encapsulate the fact that the streams are in a pool, I placed them into a pooled_object template class which simply creates a pool object of type T from pool instance P, and then created typedefs so that the template parameters were hidden behind type names. The pooled_object's destructor takes care of destroying the object.

Retrieving one of these pooled streams is simplicity itself; you just instantiate a pooled_istream or pooled_ostream, which goes through the chain of adaptation code, eventually reserving a buffer, presenting a standard stream interface, etc. The character send/receive functions are used to serialize data across a socket, so they call the overloaded serialize virtual member functions to perform input and output. Remember to call any immediate base classes versions of serialize from within a derived class's serialize functions, and everything should go smoothly.

Since the pooled_istream and pooled_ostream classes provide a conversion operator to std::istream and std::ostream, you can design the serialize functions to use std::istream and std::ostream, while passing a pooled_istream/pooled_ostream object, in which case the conversion allowed by the operator istream&/ostream& will give you the stringstream interface to the multiple i/o socket buffers.

Simple, eh? The serialize member functions are borrowed from MFC's CArchive class, the adaptors from The C++ Programming Language, Special Edition, and the pool data structure from Magmai's post.

EDIT: Changed behavior of pool slightly to contain capacity for streams rather than actual streams, and also changed the pooled_object typedef so that it works.

Edited by - null_pointer on January 15, 2002 9:39:26 AM

I implemented a system of shared buffers with a pool of shared stream interfaces to those buffers, and hid all that code into two function calls.

When you call character::send (), here is what happens. First, a temporary pooled_ostream object is constructed, which retrieves a osocketstream from the global pool of i/o streams, which in turn retrieves exclusive access to a buffer from socketmultibuffer. (The purpose of socketmultibuffer is to manage multiple shared buffers and inserts/extracts them into/out of the socket''s single buffer at the proper time. Each time you get an input buffer, its contents are extracted from the socket. Each time you release an output buffer, its contents are inserted into the socket class''s single output buffer.)

After the temporary pooled_istream object is constructed, the compiler tries to convert it to an ostream& (in order to pass it to character::serialize (ostream&)) and finds the conversion path pooled_ostream->osocketstream&->ostream&, via the chain of conversion operators. So in effect, character::serialize gets a temporary, standard output stream interface to one of a pool of output buffers (to which it has exclusive access), and all through one constructor call. Note how elegant this is; no details of the shared buffer/stream implementation leak into the character classes - for all they know they are all writing into the same buffer.

After the call to character::serialize has been completed, the temporary object is destroyed, destroying the temporary output stream interface and releasing the buffer for use by another instance of a character-derived class. The chicanery of socket::multi/Xsocketstream/Xput_streams/pooled_Xstream class really just adds transparent support for a socket class using multiple buffers, and then abstracts the fact that it does. Unfortunately, due to the way this code was written, unless you are using multiple threads to write to the socket there is no use for it; no calls to character::send will simultaneously, and thus only one stream/buffer pair will ever be used. Massive overkill.

Anyway, it does demonstrate how you can abstract the storage of buffers and streams as well as abstracting the relation between a stream buffer and a stream interface, while still maintaining the standard stream interfaces and all the functionality they bring with them. However, it does not really overcome the problem you wanted to fix...

quote:Original post by Kylotan

They were just mentioned to justify the fact that I need to buffer the data after formatting it. All the formatting takes place as the data is passed to the Character and is completely done before it is even considered for sending to the socket. Note that this is done for all Characters in the game: all the buffers are filled, then all the buffers are emptied.

Must all buffers really be in use at the same time, or could you find some scheme for sharing buffers among instances of character?

If in your program each instance of character must have its own buffer, then I am afraid that the ideal solution to your problem does not exist. You must: 1) pay the memory overhead of having a stream for each character, or 2) pay the execution time overhead of constructing a stream for each buffer, or 3) some tradeoff between the two. Magmai''s suggestion of pooled stream interfaces does not actually solve anything if a stream must be attached to a buffer for each character; if you can find some way of sharing the buffers then you may be able to reduce this cost.

The only possibility that I can see for a tradeoff would be if you could process the characters in a different order each time; then you could keep a pool of stringstreams that can remain attached to some character buffers between two calls of the loop code. With this method you could have a tradeoff between the memory overhead and speed overhead by choosing the total number of stringstreams. This is not a very good solution, but it is still an option...I''m getting tired.