Lars Viklund wrote:
On Sun, Jul 08, 2012 at 07:53:56AM -0800, Robert Ramey wrote:
On could implement this as a standard conforming code_convert facet which could then be attached to any stream. Actually there might be room in boost for a code_convert facet library based on composed/nested iteratator adaptors.
No, you misunderstand me.
Why does it have to only be a stream filter or codecvt facet? What's wrong with some nice light low-level free functions or classes, on top of which you can build whatever fancy abstractions you want.
Streams and codecvts are fine and all, but very often way too much fluff around a very simple algorithm that shouldn't need such plumbing.
I think we're in agreement here. The "dataflow iterators" of the serialization library is what I aways envisioned for this. It's really a "filter construction kit". The filters used by the serialization library (and there a number of them) are constructed by composing simpler ones to create a higher level one. So you only need to include enough code to get what you want. I stopped polishing it when it was good enough build all the filters that the serialization library required. Later boost range came about which is a more complete implementation of this idea. It always seemed to me that it would be interesting to use this approach to compose code_convert facets to taste. But code_convert facets aren't all that popular so the idea. So it's not clear that this would be a worthwhile project. Robert Ramey