I agree (with whatever point you were trying to make.) The concern of what you call "dataflow iterator adapter" is definitely quite separated from specific codepoint or encoding concerns. /David NOTE: yes, I top posted here sorry. Typed on an iPhone On Mar 7, 2010, at 4:59 PM, "Robert Ramey" <ramey@rrsd.com> wrote:
Andrew Sutton wrote:
Concerning Unicode, I did the foolish choice this year of working full-time as the same time as I finish my studies, which hasn't left me as much free time as I would have liked it to. I will be resuming work on it this summer, however, as I am quite keen on getting it into Boost.
One concern I have is that it is quite close to Boost.Iterator, Boost.Range, Boost.RangeEx and Boost.StringAlgo, and I would like my changes to be added as improvement upon those libraries if possible. But I guess proposing everything under Boost.Unicode makes it quite easier to review and all.
Here is some information which may or may not be relevant here.
a) A number of years ago, I needed a codecvt facet to output UTF-8. I found one written by our own Ron Garcia. I checked it in as part of the seriailization library. It's been hassle free for all this time. I believe that others have used it as well.
b) As I recall, the original code also included the above conversion as an iterator - I don't see that code around any more.
c) Also as part of the library I needed a bunch of converters (multi-byte <-> unicode, etc) which needed to be composed with a bunch of other filters (base64, etc.). I made "dataflow iterators" which use just the addition of templated constructors to the boost iterators. All this has worked well as large part of the implementation occurs at compile time.
d) In the meantime boost.iostreams got made which also included some of this facility. This code isn't part of the codecvt facet machinery - which is where I would think it should be.
Soooooo - from my perspective, I would like to see.
a) templated constructors added to boost.iterators b) a bunch of iterator adaptors - some of which are like "dataflow iterators". c) a class for construction a codecvt facet out any iterator adaptor.
Previous efforts at a unicode library have seemed to bog down in codepoints and whole lot of other stuff I don't understand.
I don't know that I have a real point here. But for a long time it has seemed to be a lost opportunity to unify a bunch of stuff which seems to be re-invented all the time.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost