[Boost-users] boost::iostreams - user defined format flags

From: Alan M. Carroll (amc_at_[hidden])
Date: 2005-08-08 11:24:17

I'm trying to use the boost::iostreams library but I've run in to a problem that makes that difficult.

The basis is that I want to write manipulators to manipulate the behavior of the filters in a filtering iostream. The standard mechanism for such manipulators are user defined format flags for streams, accessed via xalloc() and iword()/pword(). These are not available in a filter. It is also not feasible to store the formatting state in the filters, as there are not accessible from the filtering stream (and hence inaccessible to the manipulators).

I exchanged an e-mail with the author in which he states that a forthcoming version of boost::iostreams will provide access to the filters from the stream object. Manipulators could then reach in to the filter objects and modify them to adjust formatting behavior. However, while this is desirable for other reasons, I'd prefer to be able to use iword/pword from the filters, i.e. be able to call these methods on the Sources and Sinks (which, presumably, would forward them to the actual stream). It seems more "standard" to me, although one could argue for storing state directly in the filters from a clean design point of view.

Does anyone else have an opinion on this? Or have a suggestion for an alternate method of creating manipulators to adjust the behavior of the filters using stream local state? I searched around for  previous discussion of this issue but didn't find one. If there was, a pointer to it would be much appreciated.

P.S. For those interested, the details of what I want follow.

I'm doing some work with XML which involves user input. Because one never knows what a user might put in his data, I need to encode/decode problematic characters such as angle brackets. The problem with having streams to do the encode/decode is that one doesn't always want this performed on the data. For instance, during output one needs to send literal angle brackets around the element tags and I don't want to get in to trying to second guess the encoder to work around it. The solution I decided to implement is to have manipulators that turn the coding on and off, so one would do something like this:

xml::coding::ostream s;
s << "<tag>" << xml::coding::on << node.content() << xml::coding::off << "</tag>";

This allows low level code fine grained control over what gets coded while leaving the details up to the stream provided by the application. The hassle of setting up strings for in place conversions is also avoid, along with the problem of making sure every body is using the same coding algorithms.  However, it doesn't help all that much on input as a parser has to read from a non-filtered stream to correctly detect the tags. Element content will end up in a string and it's no easier to use a filtering stream on that than to just call a decode function.