В Qt с версии 5.5 по-тихому изменили работу qDebug()

Зачем писать кириллицей в дебаг? Может у вас ещё и комментарии в коде на русском?

Автор треда неверно описал проблему. Дело не в кирилице в исходном коде, а в переопределённом операторе qDebug() << QString. Неважно откуда взялась эта строка, теперь при попытке залогировать её содержимое будут выводиться коды юникода вместо текста.

Каковы пути обхода этой проблемы?

У этого Thiago ЧСВ пробивает все мысленные и немыслимые границы.

Сейчас он в багтрекере объясняет, что логировать через qDebug нельзя было никогда. Мол эта функция исключительно для отладочных сообщений, которые нужно не читать, а отправлять разработчику, который должен будет пропустить сей выхлоп через декодер. А все кто логировал делали это неправильно и должны исправить все qDebug() на qDebug().noquote(), которую добавили в 5.5. Интересно что он ответит на вопрос как теперь сохранить совместимость исходного кода между 5.5 и предыдущими версиями, в которых небыло noquote.

В пятёре qDebug работает через setCodecForLocale.

Это где такое? УМВР без всяких костылей. Да и в доках написано, что только для «some applications that want to use their own mechanism for setting the local»

Странно, что никто не вспомнил про qInstallMsgHandler.

В хендлер попадает уже сконвертированная строка с кракозябрами. Да-да, это не баг, так и задумано.

Мол эта функция исключительно для отладочных сообщений

Мда... А лог тогда для чего?

Почему setCodecForLocale не показываешь, или ты с Qt4 сразу на 5.5 пересел?

В том и дело, что начиная с 5.5 они игнорируют codecForLocale и всегда выводят закодированную строку.

Каковы пути обхода этой проблемы?

Согласно автору сего эпичного изменения научиться читать текст сразу в кодах юникода:

I've conceded that it makes reading of non-English text more difficult. Sorry, you can't win all cases. I'm saying that this is a positive trade-off.

Просто more difficult. А так positive trade-off.

я не спец в Qt, но вижу, что это юникод. может, просто консоль перевести в юникод и будет выводиться нормально?
вообще, юникод - это хорошо. всякие самопальные разношёрстные кодировки должны уйти со временем и останется единое и универсальное представление. к этому потихоньку всё и идёт.

я не спец в Qt, но вижу, что это юникод

В том и дело, что это уже не юникод, а коды юникода в ASCII вперемешку с остальным форматированием. Другими словами, обратной декодировке в общем случае не подлежит.

Мда... А лог тогда для чего?

Согласно Тьяго, есть лог, а есть отладочный лог. И он настоятельно просит не путать эти две кардинально разные сущности. В отладочный лог должен попадать нечитабельный мусор, отсылаемый разработчику для дальнейшего анализа. А неотладочного лога в Qt никогда и небыло (-: Deal with it.

А сломал там всё, как обычно, Kai Köhne? Чей коммит внёс такое поведение?

ЛОЛ, до сих пор не пробовал выводить киррилицу через qDebug().

А в камментах там знатно бомбануло. Не представляю, зачем выводить кирилицу черзе qDebug, ещё бы на иероглифы пожаловались..

Это где такое? УМВР без всяких костылей.

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

Во вторых, это не костыли а фича для тех кто не хочет нагромрждать код перекодировки на каждом месте вывода отладочных.

ИМХО конечно но Thiago абсолютно прав. Кто логировал через qDebug тот ССЗБ. Для логов есть файлы или даже целые библиотеки. Это лишь qDebug это лишь отладочная инфа(что из названия следует) для выплевывания в консольку.

как теперь сохранить совместимость исходного кода между 5.5 и предыдущими версиями

ССЗБ же, страдай если используешь функции не по назначению.

QMessageLogger использовать стоило бы.

Не представляю, зачем выводить кирилицу черзе qDebug

К примеру залогировать путь к файлу. Или имя/фамилию. Да любой читабельный текст полученный откуда угодно.

Доки, вполне себе конкретные. Если бы ты их прочитал, ты не лепил бы что то вроде

я не хочу заводить autoinclude хедер только ради переопределения одного макроса

А уже давно решил бы проблемму. А если я кину тебе ссылку, то ты о5 пойдёшь плакать на лор и мозг есть разрабам, вместо прочтения доки (я не говорю уж про сорцы).

Так они с тем же успехом могли пропустить содержимое строки через zlib+base64. А на вопрос что с этим выхлопом делать ответ был бы:

ССЗБ же, страдай если используешь функции не по назначению.

qDebug это лишь отладочная инфа(что из названия следует) для выплевывания в консольку.

В Qt с версии 5.5 по-тихому изменили работу qDebug() (комментарий)

К примеру залогировать путь к файлу.

/0

Или имя/фамилию. Да любой читабельный текст полученный откуда угодно.

Могу согласиться, но это правда не настолько частый use case.

Могу согласиться, но это правда не настолько частый use case.

Логировать текст не настолько частый use case? Или вы у себя исключительно названия переменных логируете?

Я больше использую что-то типа «Before..», «After..» и т.п. Если мне нужен именно текст, то отладки достаточно.

qPrintable - не костыль, а правильный метод конвертации для вывода на консоль. Предлагающие всякие другие костыли все упоролись.

думаю, надо поковыряться с настройками кодировки, которую Qt использует по умолчанию, и с настройками консоли. ну и код, естессна, должен быть в юникоде.
как вариант, можно скормить этот выхлоп какому-нить скрипту, который его переведёт в читабельный вид. echo -en умеет такое печатать. правда, там ещё и пробелы и местами \u отсутствует, так что придётся повозиться.

В данный момент у меня именно такой проект, как раз на qt. qDebug максимум должен указать почему все плохо и где, а не выплевывать значения переменных\ячеек. Если нужно смотреть переменные есть стандартные средства отладки IDE.

Тебя не туда занесло. Тут смысл в том, что раньше QString'и через qDebug() << QString(«_»); отображались нормально, а сейчас всё сломали. В итоге в куче софта, где использовали подобное, вместо читабельных сообщений в консоль будет выплёвывать нечто несуразное, вроде «\u0447\u0435\u0442\u044B\u0440\u0435».

qDebug максимум должен указать почему все плохо и где, а не выплевывать значения переменных\ячеек.

Да что ты говоришь! А я вот открываю документацию и вижу:

    qDebug() << "Date:" << QDate::currentDate();
    qDebug() << "Types:" << QString("String") << QChar('x') << QRect(0, 10, 50, 40);
    qDebug() << "Custom coordinate type:" << coordinate;

http://doc.qt.io/qt-5/qdebug.html#details

qDebug() << "Widget" << widget << "at position" << widget->pos();

http://doc.qt.io/qt-5/debug.html#warning-and-debugging-messages

И даже вот: http://doc.qt.io/qt-5/qtglobal.html#qDebug

Почитал.

Тьяго прав, чо.

мне вообще кажется, что debug statements должны быть на английском и ни на каком иначе

У меня нет возможности сейчас проверить что они накрутили там в Qt 5.5

Я правильно понял, что qDebug() << QString("текст"); и qDebug() << QString("text"); будут выдавать внутреннее представление QString в Unicode-Escape последовательностях? Или же только в том случае, где использована кириллица?

и останется единое и универсальное жирное представление

fxd

И это не юникод, это экранированный юникод. Видимо, как раз для неюникодных консолей и сделали, потому что если выплюнуть туда юникод как есть — будут кракозябры.

тоже на это напоролся ) но решил легко т.к. логировала единая функция - там добавил qPrintable но остались моменты, где qt сам выводит в qDebug - например об ошибке argument missing для arg в qstring считаю, что разработчики неверно поступили пойду почитаю багрепорт

еще момент - qInstallMessageHandler получает уже кореженный qstring

qPrintable - не костыль, а правильный метод конвертации для вывода на консоль.

Ага, а на выходе char *. Убивать за такое надо.

А что должно быть на выходе? Чтобы учесть потребности людей, предки которых решили напридумывать сотни тысяч иероглифов, придется использовать четырехбайтные символы, а это уже ни в какие ворота. А за char* вполне может скрываться строка в UTF-8.

сотни тысяч иероглифов,

Иероглифов тыщ 70 всего.

А всяких смайликов с кучей оттенков кожи?

интересный они там аргумент приводят: qdebug это вывод для разработчик, а не для лога )
если мне пришлют (как разработчику) такой «удобный» вывод от qdebug - я наверно не буду этому рад )
еще идиотский аргумент - видеть не содержимое строки, а байты - никогда не требовалось видеть в qstring нечто иное чем ее содержимое
жаль мне того Thiago Macieira - много он о себе узнает нового )

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

жаль мне того Thiago Macieira - много он о себе узнает нового )

Сломал-то, наверняка, Kai Köhne. Он любит хотфиксы в мастер засылать без проверки. Вот его недавнее творчество с шрифтами на GNU/Linux:

Было: http://lists.qt-project.org/pipermail/qt-creator/attachments/20150522/f03f25e...

Стало: http://lists.qt-project.org/pipermail/qt-creator/attachments/20150522/f03f25e...

Он на OS X сидит, вот и не заметил, что «рендеринг шрифтов OS X в ветку Linux закоммитил».

Я вообще не понимаю, у них есть тестеры или нет?

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

Ты нитью промазал. Я солидарен с тобой:

В Qt с версии 5.5 по-тихому изменили работу qDebug() (комментарий)

Я вообще не понимаю, у них есть тестеры или нет?

со шрифтами они не оттестили, да
но тут то поломали сознательно и это печалит
потом скажут что qdebug вообще для них самих только, а в документацию забыли это написать )

В документации оно у них как раз предназначено для вывода всяких переменных. Я выше кидал ссылки :)

не, я имею ввиду что они меняют внутри чтото, а потом задним числом говорят, что «документация неверна» и qdebug так нельзя было )

конечно я не согласен с этой поломкой

Ребят, ну вы флудеры, ответьте предложите workaround означенной проблемы. Я тупо хочу выводить через qDebug строки с кириллицей. Каков путь решения? Огорчен что это меняется в Qt 5.5.

Кто-нибудь попробуйте noquote из ссылки ТС-а в начале темы. У меня нет возможности проверить, через мопед сижу...

noquote работает, проверено. Просто это неудобно и получается бред когда функция используется совсем не для того чего задекларирована

я бы понял если бы она называлась noescape, но noquote то зачем делать функций двойного назначения?

Серьезный вроде бы фреймворк а очевидные ошики в дизайне допускают как джуниоры