странно. а для чего тогда в стандарт ввели расширенные символы? как их предлагаешь использовать без строки?

Юникод, имеющий одинаковый размер для любых символов, это и нужно использовать.

boostcoder, я скажу свое имхо.
В string или в char* нелья использовать UTF8, (Ну только если считать, записать и все). Любое мало-мальски активное использование ведет к нехорошим вещам.
Потому-что риск получить в итоге глючную, невменяемую программу - очень высок.
Гораздо выше, например чем при использвании printf. Но про принтф, все обязательно любят повозмущаться, что де это нарушение безопастности типов, и т.д, и т.п. В принципе я согласен, но в реале, я никогда не встречал проблем с printf'ом.
А вот с UTF8, я встречал и встречаю очень часто. Скажу даже больше, буквально в любой программе, которая активно использует UTF8 с нац. символами - будет ошибка! ну в 99,5%, может быть.   

Почему-же так люди возмущаются на printf, и спокойно используют UTF8?
Потому-что дядя Страус, так сказал... Но про UTF8, он как-то не обмолвился...
Знал бы он что с этим программеры делают... думаю ужаснулся бы старик..

Предлагаю всем такую задачку, не будем брать сложное. Возьмем самое элементарное, для начинающих:
Написать функцию возвращающую истину, если в строке есть русская 'А', и ложь, если ее там нет.
На вход подается UTF8 строка содержащая произвольные расширенные (в т.ч. может быть и латинские) символы.

Я не знаю как без привлечения "высшей математики", написать такую функцию.
Чтоб не скучно было, (++rep)  любому, кто напишет правильную функцию, используя стандартые средства    


Это сообщение отредактировал(а) volatile - 25.4.2012, 00:59

Ваша функция матюкается (куча warning'ов), но работает
http://liveworkspace.org/code/ba64c628d664...dce4f854bc80ebe
и даже так
http://liveworkspace.org/code/8c3d9e5dbf29...b70acb5eed65b72

так что volatile.rep++;   

вот исправленные версии варианта borisbn.
http://liveworkspace.org/code/6455efa5ee33...227d30e08dbe48a
http://liveworkspace.org/code/1e9d68b3a883...837e658c28a0a8c



страшные вещи ты говоришь.
никогда не использовал другого юникода кроме UTF8. и с UTF8 никаких проблем не замечал.

гыыы. а чего ж результаты отличаются ?


м.б. потому, что с русскими буквами не работал ? Только с английскими ?

Это сообщение отредактировал(а) borisbn - 25.4.2012, 09:01

потому что в строке 'Тут русская ' - 22 байта.
буква 'A' - 23


Это сообщение отредактировал(а) boostcoder - 25.4.2012, 09:15

я про это

Вывод

http://liveworkspace.org/code/2bb3580795d1...83e17a424a71632

русская 'А' состоит из двух байт.
поэтому where_russsianA_char() не должна корректно работать.

Добавлено через 58 секунд
я использую эту хидер-онли, STL совместимую, микро-либу.

однако ж ) 


Вы смешиваете понятие "строка" с понятием "контейнер для строки"..  Это не "специальный" юникод имеет одинаковую ширину символа, а юникод помещает в такой контейнер, ячейка которого способна вместить любой символ юникода.. Ну а выбор контейнера зависит от задачи.. 
Если нужно оперировать посимвольно, то конечно лучше широкосимвольная строка, но есть ряд задач когда односимвольная строка будет подходящим контейнером.. 


если знаешь с чем работаешь - никакой пропасти 

Добавлено через 5 минут и 12 секунд
P.S. о том, в какой кодировке хранить исходники, отдельный вопрос ..  В любой случае при использовании нац символов это ложится на плечи программиста и должно согласовываться отдельным соглашением.. 

Спасибо друзья! Спасибо что лишний раз наглядно показали, что использовать utf8 - крайне опасно.
Увы, ни одна из ваших функций не правильна.

Рассмотрю только последнюю, "исправленную" версию от boostcoder
(варианты от borisbn, как минимум страдают тем же самым)

Итак

Программа ищет подстроку "А" в заданной строке. Вроде бы все ок, не так ли?
Но давайте внимательно посмотрим, что происходит.
hex представление буквы А в utf8 :


Теперь рассмотрим строку в которой происходит поиск. Допустим она состоит из двух букв "XY"
Пусть на месте буквы Х находится любой символ с кодировкой: 
 (Вместо ?? подставьте любой код в диапазоне 80-FF)

а на месте буквы Y находится любой символ с кодировкой:


Соответственно, вся строка "XY", выглядит так:

Таких сочетаний, как вы понимаете 128*128= 16384 штук

Отправляем одну из таких строк "XY" на поиск в ней русской 'А', и о чудо!, в троке "XY" оказывается присутствует 'A'!

Тут можно возразить что строки "XY" никогда не встретятся.
А вы точно сможете дать гарантию, что ни один из 16384 вариантов, никогда не встретится ?
Это одни из тех багов, которые сидят в программах вечно, и когда-нибудь, по законам Мерфи в момент когда смогут нанести максимальный ущерб, они сработают.
И вся беда в том, что такая ошибка не ловится. Она просто не воспроизводится у программиста.
И он матерится на "долбанных юзеров", у которых баги, неизвестно откуда..

Напомю, здесь мы рассмотрели только самый невинный вариант - Поиск символа в константной строке.
Варианты с форматированием винчестера, на отрицательный ответ юзера, оставляю на вашу фантазию...


Аболютно универсальный ответ, на любое сомнитльное решение.   


Это сообщение отредактировал(а) volatile - 26.4.2012, 00:30

слишком много букаф %)
воспроизведи то о чем говоришь, в примере.

boostcoder, В принципе хоть букв и много, смысл там простой. Может найтись случайное сочетание, которое даст ложное срабатывание.

Ладно, ребята. убеждать не буду, больше.
Используйте utf8
В принципе mes, провильно сказал.


Просто я много раз видел, когда например под отведенные три символа английских, поверх писали 3 символа русских.
Щас просто, не приходят в голову все варианты багов которые я видел.
Дай бог чтоб у вас такого никогда не было.

остается гадать...

volatile, только не подумайте, что я защищаю utf-8 в программах. Я как раз противник этой недокодировки (кроме передачи данных) и нигде в исходниках её не использую.
Однако, Вы неправы насчёт того, что комбинация, похожая на 'А' может появиться из двух половинок двух символов. Дело в том, что любая русская буква состоит из двух таких байт

и ситуации

быть не может в принципе.

источник