Boost logo

Boost :

From: Sean Parent (sparent_at_[hidden])
Date: 2006-07-06 00:33:56

> 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

> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at