[boost] Re: IOStreams formal review start

From: Larry Evans (cppljevans_at_[hidden])
Date: 2004-08-31 18:41:36

On 08/31/2004 04:55 PM, Carlo Wood wrote:
[snip]
> My idea then would involve the introduction of a 'message' object,
> something that abstracts a contiguous piece of data with a finite
> size that can be processed as a unit.  For example, one line of
> text in the case of text filters - or one packet of data when
> processing a UDP stream - or one binary packet that starts with
> an envelope/header followed by a payload etc.
> 
> Then, instead of passing (buf, buf + n), this more abstract 'message'
> object should be used then.  The message object would contain the
> 'buf' pointer and the size 'n' - not the complete data of course.
> Purely for exposition:
> 
> struct Message {
>   char* buf;
>   size_t n;
> };
> 
> A filter should then be allowed to do the follow things with this
> object:
> 
> 1) Tell it that the data can be freed.
>    If the data is still in the original streambuf then the
>    message object would take care of telling the streambuf
>    that the part it was holding is now free again.
> 
> 2) Process it inline - it would not write outside the buffer
>    but only examine it and change things perhaps such that
>    the result still fits in the same buffer.
> 
> 3) Copy the data to a newly allocated memory block (which now
>    can be larger than the orginal), filtering it while copying
>    it if needed.  This means that the 'message object' tells
>    the streambuf that the data is now freed.  Subsequential
>    'freeing' of the message would now delete the allocated
>    memory block and not that of the stream buf.
> 
> To the user of the 'message' only this interface would be
> visible (for example):
> 
> Message::start() const		: Get the start of the message.
> Message::size() const		: Get the size of the message.
> Message::reserved() const	: Size of the allocated buffer.
> Message::reserve(size)		: Increase buffer size (possibly causing a copy).
> Message::set_size(size)		: Set a new message size.
> Message::~Message		: Free the underlaying data and destruct the message object.
> Message::Message(size)		: Create a new Message object with an uninitialized
> 				  buffer of size 'size'.
> 
[snip]

I haven't thought deeply about this, but could this message idea and
stack of streambuf's be used to implement a part of the upper layers
of the OSI model:

http://www.geocities.com/SiliconValley/Monitor/3131/ne/osimodel.html

?  For example, each layer would correspond to an element in the stack
of streambufs, and each streambuf could have a state associated with it.
For example, the state could be a complex fsm, as with TCP:
 
http://www.tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF.htm

In another application, indenting output to reflect code structure, the 
state could be a simple flag, bol (beginning-of-line), to indicate the
next character output will be the first on the line, and a length, to
indicate the width of the current margin.  An example of a streambuf
with such a simple state is:

http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/io/filters/ofilter_leftmargin_adjustable.hpp?view=markup

Jonathan, I'll be trying to rewrite the above code with IOStreams.
looks like it'll be very easy.  I'll just have to add the same member
variables in the above code to that in your example:

   toupper_output_filter;

and rename it, of course, and change the put to check the bol flag and 
print the margin before outputing the character.  Then add a method
to adjust the margin length.

BTW, Jonathan, the documentation looks very good.  I'll use it as a
model if I ever try to get anything submitted.

Regards,

Larry.