
6 Jul
2006
6 Jul
'06
4:33 a.m.
> This is very close to what I have in mind. The main difference is that > the functions/algorithms in my mind take ranges instead of iterators. > Thus: > > to_lower(src, dest) > to_upper(src, dest) So long as you don't require ranges (or a pair of iterators makes a valid range and dest can still be an output iterator). That's fine - these should work on char* as well as container types. I don't know what kind of ranges you have for dest which allow dest to change size - seems a bit problematic. I want iterators that can handle the encoding transform. I want to be able to write items like the following: std::string s = get_some_utf_8_xml_data(); // Find the BOM character as a UTF-32 character utf_iterator_t i = std::find(utf_iterator_t(s.begin()), utf_iterator_t (s.end()), UL0x0000FEFF); assert(*i.base() == U0xEF); // base iterator points to start of UTF-8 character Sean > With these, I could make Fusion like wrappers that transform them into > something like: > > some_string s1 = to_lower(src); > some_string s2 = to_upper(src); > > where to_lower and to_upper return cheap views that are in and by > themselves valid strings/ranges. They are cheap because the actual > conversions/transformations are done on demand-- think lazy > evaluation. > So, like those done by expression template techniques, there are > no expensive temporaries when you perform seemingly expensive tasks > like: > > some_string s = f1(f2(f3(f4(src)))); > > And yes, because they are generic, those string algorithms can work > on any string type that satisfy some basic requirements. > > Regards, > > -- > Joel de Guzman > http://www.boost-consulting.com > http://spirit.sf.net