Здравствуйте, Roman Odaisky, Вы писали:

C>>Проблема будет при попытке развернуть строку, содержащую многобайтный символ (который при этом вывернется наизнанку и станет невалидным). Или строку Unicode, содержащую суррогатные пары (которые тоже вывернутся наизнанку) или nonspacing диакритику в decomposed форме (которая уйдёт на соседнюю букву).

RO>Кстати, да. Но такой проблемы не будет, если итераторы сделать правильно. Как-то так:
RO>

RO>OctetStream utf8string;
RO>Utf8Iterator const first = begin<Utf8>(utf8string);
RO>Utf8Iterator const last = end<Utf8>(utf8string);

RO>doSomething(first, last);
RO>doSomething(std::reverse_iterator<Utf8Iterator>(last), std::reverse_iterator<Utf8Iterator>(first));
RO>

Да. Вот только в этом коде некий гипотетический тип Utf8 должен быть опять-таки строчкой байт либо достаточно широким символьным типом. А если добавить ещё и обработку диакритики (и соответственно типы Grapheme и GraphemeIterator), то реализация станет сложной, а оптимизация — трудной. Ни о каком произвольном доступе к графемам за O(1), конечно, не стоит и мечтать — разве что индексировать строку при первом использовании…

Кстати, в свете юникода стоит отметить ещё одну проблему со строками вообще и со строками в C++ в частности. Строки иногда очень хочется сделать ключом map’а или ещё как-нибудь отсортировать. При этом нужен предикат порядка над строками. А он — surprise! — разный для разных человеческих языков и в общем случае не сводится к поэлементному сравнению (как это предполагает std::char_traits). Кто здесь когда последний раз инстанцировал std::map<std::wstring, T, std::locale>?