Russian Qt Forum

Это не решение - это костыль.

В смысле?! Так работает, а что в этом методе хромого?))

В смысле?! Так работает, а что в этом методе хромого?))

В исходниках нет возможности указать кодировку.
Другой юзер отредактирует этот код в другом редакторе или в другой кодировке и всё - поплывёт твой русский.
Поэтому все строковые "неродные" константы в коде нужно прописывать на английском или в isoLatin1 в tr() и уже потом переводить на русский и какой ещё язык. И это должно быть правилом.

Если править файл в его кодировке, то проблем не будет.
А если в выставлен кодек для си строк, то дважды не будет.

"в его кодировке" - эта инфа где-то прописывается? Нет, поэтому чушь несёшь.

В смысле?! Так работает, а что в этом методе хромого?))

C++ (Qt)
QStringList lst;
      lst << QObject::tr( "Common" ) 
          << QObject::tr( "Map" )
          << QObject::tr( "Palette" );
 

Никогда не пиши программы по принципу "раз работает, значит пойдёт". То что пытаешься сделать описано в 1) стандарте С++ 2) документации Qt. Правильный способ - использовать английский текст и переводить его через tr():

Так и написано "Единственно правильный способ"?

Правильный - да. Возможный - нет.

Другой юзер отредактирует этот код в другом редакторе или в другой кодировке и всё - поплывёт твой русский.

Пытаюсь представить себе эту ситуацию и никак... Этот, другой, когда открывает текст для правок, не видит, что он  в кракозябрах? Или он корректирует какую-то часть, не обращая внимания на остальной текст?

А если проект русскоязычный? Зачем такие сложности, не проще ли команде разработчиков договориться о кодировке исходников?

А где это написано можешь привести?

2.1.1

Physical source file characters are mapped, in an implementation-defined manner, to the basic source
character set (introducing new-line characters for end-of-line indicators) if necessary. Trigraph
sequences (2.3) are replaced by corresponding single-character internal representations. Any source file
character not in the basic source character set (2.2) is replaced by the universal-character-name that designates
that character. (An implementation may use any internal encoding, so long as an actual
extended character encountered in the source file, and the same extended character expressed in the
source file as a universal-character-name (i.e. using the \uXXXX notation), are handled equivalently.)

2.2.1

The basic source character set consists of 96 characters: the space character, the control characters representing
horizontal tab, vertical tab, form feed, and new-line, plus the following 91 graphical characters:15)
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
_ { } [ ] # ( ) < > % : ; . ? * + - / ˆ & | ˜ ! = , \ " ’

However, if you want to write portable code, we recommend that you avoid non-ASCII characters in your source files. You can still specify non-ASCII characters portably using escape sequences, for example:

label->setText(tr("F\374r \310lise"));

В приведенном отрывке стандарта вводится понятие базового набора символов (base character set) и описание процесса работы с символами которые не входят в базовый набор.
Разве отсюда следует, что нужно и/или можно использовать только базовый?

Насчет второго отрывка: "...if you want to write portable code, we recommend...". Это рекомендация.

Что ты посоветуешь насчет комментариев? Ты тактично умолчал.

"Any source file character not in the basic source character set (2.2) is replaced by the universal-character-name that designates".  Отсюда в gcc на разных платформах иногда начинают лезть ошибки типа "stray \xxx\xxx..." in program.

Рекомендация чтобы писать портабельный код. Ты МОЖЕШЬ писать непортабельный код, но будет ли он согласовываться со стандартом - это отдельный вопрос. В твоём случае не будет.

А  что тут говорить, по стандарту - нельзя. По факту - можно, т.к. все известные мне реализации тупо пропускают текст между символами комментария /* */ или //, то есть писать там можно всё что угодно.

Это говорит лишь об ущербности этой версии или о том, что она как раз не поддерживает universal-character-name.
Но никак не о том, что так делать нельзя.

Это смотря насколько широко рассматривать портабельность.
Если я точно знаю, что мне не потребуется локализация моего приложения. То зачем мне tr?
Одни и те же исходники с русским строками прекрасно собираются и в линукс, и в винде. Без каких либо конвертаций и преобразований.
И нет никаких "модных" проблем с кодировкой. Может я что-то не так делаю? )

Да почему нельзя-то никак не пойму?
Ты привел текст в котором написано, что не ASCII-символы при компиляции будут заменены на последовательность вида \xxx.
Почему отсюда вывод, что нельзя?

Конечно нельзя, пример с UTF BOM - яркий пример. В gcc не зря есть флаг, который задаёт кодировку исходника, совсем не зря.

Ты просто живёшь в счастливое время UTF-8. Скажем, лет восемь назад в том же Линуксе у всех были разные локали, и исходники написанные в разных дистрибутивах имели бы разную кодировку.  Если это работает здесь и сейчас - хорошо. Является ли это правильным решением? Ответь сам на вопрос.

Стандарт ведь не дураки пишут ;) Между прочим, аналогичная ситуация с ID3 тегами в MP3.

Я подумал, и в принципе здесь ты прав, потому что опять же исходя из реалий, что компилятор просто пропускает этот текст.

Конечно не дураки, но пока что мы не обнаружили строк, которые запрещают использовать в исходниках символы отличные от ASCII (Пантер, наверное с ума сходит, читая этот тред : ). Я хочу чтобы меня аргументированно убедили.

Как это пропускает, если printf("Очень русский текст\n"); выведет на консоль сам знаешь что)
Я думаю, это сделано лишь для обратной совместимости, для того, чтобы старые версии компиляторов могли внятно объяснить, почему этот исходник не может быть скомпилен (я могу ошибаться).

$ ./qt4-template
����� ������� �����

update: кстати а что делать, если человек который будет смотреть проект, незнает английского? :)

Пантер, вот ненадо фатализма ;) Есть нужные люди, незнающие английского. И не обязательно программные.

Как это не обнаружили?

"Physical source file characters are mapped, in an implementation-defined manner, to the basic source character set (introducing new-line characters for end-of-line indicators) if necessary". И далее: "Any source file character not in the basic source character set (2.2) is replaced by the universal-character-name that designates that character.", а это значит, что все строковые литералы зависят от кодировки файла! Поменял кодировку - и тю-тю. Откуда компилятор знает, что ты имел ввиду? Он тупо перегонит всё в \xxx... и всё, дальше его не волнует, что русская буква "a" оказалась не на том месте в текущей кодировке.

Речь шла о комментариях, а не о самом коде.

Раз уж ты затронул printf, то покажу кое что с этим printf-ом:
Упс. А где русский текст?

$ ./a.out
Очень русский текст

А если подробно рассмотреть этот пример с printf. То нужно понять, о чем мы говорим. О gcc или о Qt?

Хотя в твоем примере, скорее проблема в кодировке файла.

Хоть что, пример-то просто с printf, а не с qDebug. Можно и с gcc, можно и с Qt.


Да ну, не может этого быть :) А как же "у меня всё работает"? А у меня не работает. Потому что счастливое стечение обстоятельств у меня не произошло.

Проблема собственно в самом Qt. В том, что по умолчанию он для const char* строк использует кодировку latin1, в которой нет набора русских символов.