что ужасного?


с этих?: http://liveworkspace.org/code/cc314ec8c914...fc9c94e5d2b157d

Это ваша LWS сохраняет исходник в UTF-8. 
GCC 4.8 + исходник в ASCII дают результат у меня 11.

А std::string - это просто контейнер char'ов, он не знает что в них.

Это сообщение отредактировал(а) Randajad - 23.4.2012, 11:54

не знал, что исходники сохраняют в других кодировках  

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

В студии:

Выход: 6

Исходник в UTF8 !!!

(впрочем не зависит от кодировки исходника.)
Имхо, так и должно быть.

А работать с UTF8 в std::string, как с обычным чар - хождение по краю пропасти.

это наверное MSVC specific?


где? почему?


отчего?

Потому-что компилятор рабоатет так, как будто нац. символов вообще не существует.
А поскольку едиственное отличие UTF8 от ASCII и заключено в нац.символах, то это тоже самое что он не понимает UTF8
Компилятор 1969 года, например, работал бы точно также.
Впрочем если в gcc это нормально, то что либо доказать линуксоидам - дело дохлое. (я, по крайней мере, пасс)


От того что вся логика стринга расчитана что там будет набор чаров, а не неизвестно что...
ну хотя бы:

Выход:
ТЕВИРП
Что вобщем-то и должно быть. разве нет?

Что будет при UTF8 - даже не берусь сказать.

reverse же ничего не знает о строке.
с чего бы он должен корректно работать со строкой?
то, что он корректно работает со строкой состоящей из однобайтовых символов - скорее совпадение, чем задумка.
ибо, этот пример работает корректно, не смотря на то что строка в UTF-8.

http://liveworkspace.org/code/24ad13a7aa89...d388bd9e2b10a8d

Это сообщение отредактировал(а) boostcoder - 23.4.2012, 14:46

В студии всё отрабатывает даже если сохранить исходник в Utf-8. Она (ну, скорее компилятор) считает русские символы в кавычках обычными однобайтовыми Си-строками. sizeof( "Привет" ) == 7. std::string str = "Привет"; str.size() == 6.
Так что приведённый пример с std::reverse отрабатывает как задумывалось...
Разница на лицо. Гнусавые опять с мелкомягкими идут своими (несовпадающими) путями.

Хотя... Мы тут сравниваем тяжёлое и сладкое. Согласно 0x11-му стандарту (!!!)


Студия же не поддерживает этот стандарт.

cp1251 ?


отчасти.
но их отказы реализовать то-то и то-то, сделают коды написанные для clang/gcc не переносимыми на их компилятор.

есть совершенно бесплатная VS Express

Это смотря как трактовать этот стандарт. По мне так, как раз она его поддерживает.
Инициализирует именно данными однобайтовыми символами,  а не юникодом, закомуфлированным под однобайтовую последовательность. (ut8 это тоже юникод)
 
Так что кто здесь отказывается поддерживать стандарт, это еще большой вопрос.
Впрочем, для стандартописателей, глубоко пофигу проблемы локализации, они кроме английского ничего никогда не знали.
Мелкомягким же приходится работать с нац. символами. Жизнь заставляет, однако.

Это сообщение отредактировал(а) volatile - 23.4.2012, 23:35

boostcoder, пример работает потомушто англицкие символы и стандартные знаки кодируются в utf-8 одним байтом.

Добавлено через 5 минут и 4 секунды
Кстати, 11-ая студия поддерживает вроде как все из C++0x. Неужели никто не пробовал? 

Это сообщение отредактировал(а) Randajad - 24.4.2012, 09:02

судя по этому она поддерживает меньше половины. В живую, правда, я её ещё не смотрел

Кстати, про utf-8. Он действительно хорош только при передаче данных по медленному или дорогому каналу. В ЯП я бы его просто запретил бы. Он там вообще нинужен

спасибо. а то я не знал.


то что она поддерживает, можно сказать - ничего. даже даже самого необходимого нет.