Static Public Member Functions | |
| static void | main (void) |
Static Private Member Functions | |
| template<class InternStrmBufType> | |
| static void | main_row_buffer_unique_with_tmp (void) |
| template<class InternStrmBufType> | |
| static void | main_row_buffer_unique_without_tmp (void) |
| static void | main_row_buffer (void) |
| The parameters is a set of streambufs which must be used for buffering. | |
| static void | main_plain_container (void) |
| static void T15_Out< OutStrmBuf >::main | ( | void | ) | [inline, static] |
| static void T15_Out< OutStrmBuf >::main_plain_container | ( | void | ) | [inline, static, private] |
Do the tests with plain STL containers as per-thread buffers. Any kinf of container can be used : We just test some of them.
The role of internal output buffers is to store the output data of the functor. Any container can be used as a sub-thread specific buffer. The interesting point, here, is that the final destination of data is a std::ostream_iterator.
| static void T15_Out< OutStrmBuf >::main_row_buffer | ( | void | ) | [inline, static, private] |
The parameters is a set of streambufs which must be used for buffering.
Plain files can be used too for buffering. We do not know yet how the temporary files will be created !!! If the internal buffer is a std::fstream (That is, basically a file), and the output iterator writes into a file too, some optimizations might be possible too.
This is one of the buffer types that we will use, and this one is in fact streamed, and based on a std::stringstream. It is possible to use any other class compatible with a std::stringstream. If the internal buffer is a std::stringstream, and the output iterator is a std::ostream, flushing can be optimised by writing the internal content of the std::stringstream, in one go.
Is it not possible to use old stdio_filebuf, RPA_STDIO_FILEBUF_OLD, in a pool of buffers, because this class has no default constructor.
It is impossible to have a pool of stdio_sync_filebuf already opened in a container, because stdio_sync_filebuf has no default constructor. So this test is not added.
| static void T15_Out< OutStrmBuf >::main_row_buffer_unique_with_tmp | ( | void | ) | [inline, static, private] |
For a given type of stream buffer, it builds a row_buffer based on it, initializes a set of stream buffers, and run the tests. The point is that we use a set of plain stream buffers, coming from anywhere else (sockets, ...) The algorithm simply plugs on them.
An array of buffers. Their associated files will be open one by one.
This is nearly equivalent but slightly faster to compile.
We can store the filenames in any datatype as long we finally convert them in 'const char *'.
This builds a couple of file names, and opens a filebuf each of them. These filebufs will be used as buffers in the STL algorithm, without being copied, just 'as is'. Any type of streambuf can be used.
We already use existing stream buffers : This is why the record buffer is based on a pointer. This tends to work only if there is a specialization for a base class of InternStrmBufType, but if not, this is just a matter of deriving and specialising the template 'streambuf_proxy'.
Does the test.
Now closes all streambuffers because it was not done by the algorithm.
| static void T15_Out< OutStrmBuf >::main_row_buffer_unique_without_tmp | ( | void | ) | [inline, static, private] |
For a given type of stream buffer, it builds a row_buffer based on it, initializes a set of stream buffers, and run the tests. Same as main_row_buffer_unique_with_tmp, but without the open/close of files.
An array of buffers. Their associated files will be open one by one.
We use already existing stream buffers : This is why the record buffer is based on a pointer. This works only if there is a specialization for InternStrmBufType.
1.4.7