LINUX.ORG.RU

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

 


1

3

Начиная с версии 5.5 на вот такой кусок кода:

qDebug() << QString("проверка кириллицы");

вам в консоль выведется

\u043F\u0440\u043E\u0432\u0435\u0440\u043A\u0430 043A\u0438\u0440\u0438\u043B\u043B\u0438\u0446\u044B

Разрабы утверждают что это intended behaviour. Я считаю что они сошли с ума.

Собственно мой багрепорт https://bugreports.qt.io/browse/QTBUG-47316


Хорошо, что я остался на 5.4.2. А после того как на работе столкнулся с непонятными глюками QUdpSocket под виндой, так и вовсе плавно перекатился на 4.8.6.

WRG ★★★★
()
Ответ на: комментарий от zekses

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

Dendy ★★★★★
()
Ответ на: комментарий от i_gnatenko_brain

Так то оно так, однако большинство приложений на Qt - не сферические в вакууме, а получают какие-то данные от пользователя, как-то их обрабатывают и выдают обратно. И вполне логично захотеть вывести через qDebug промежуточный результат обработки, чтобы если что заметить на каком этапе всё портится. А пользователь вполне может написать строку по-русски, если он говорит на этом языке.

KivApple ★★★★★
()

Хочу особо отметить, что это изменение ещё и не попало в «What's new». Только вчера Тьяго скромненько прилинковал файл где оно закопано в тонне текста к страничке апдейта. До этого узнать про это вообще не было никакой возможности если только у вас кути не собирается из репы

zekses
() автор топика

У меня есть стойкое желание форкнуть 4-ю ветку. Конечно, я мыслю здраво. Но как-то всё нехорошо выходит. А этот Тиаго вообще на Поттеринга смахивает по стилю разработки.

anonymous
()
Ответ на: комментарий от EXL

Это какие-то тухлоспайсы, судя по их форуму

zekses
() автор топика
Ответ на: комментарий от EXL

Уже есть коперспайсы. Правда они с тухлокьюта форкались.

Так и не смог их собрать, кстати. Валится на линковке из-за выжирания всей оперативы. Тут речь идёт скорее о попытке поддержать четвёрку на текущем уровне. Хотя и осознаю тот факт, что тащить такую жирноту в одиночку практически самоубийство.

anonymous
()

А по топику скажу, что на днях попробовал перенести средний проект на пятёрку. Сразу напоролся на несколько граблей. Отослал несколько тупых багов на ровном месте. И не понятно, будут ли их вообще исправлять. Ощущение, что разрабам вообще пофиг. Но главное, упала скорость отрисовки интерфейса раза в полтора-два. Если так и дело дальше пойдёт, то придётся четвёрку тянуть на сколько хватит сил. В своё время 4.5 была уже стабильным продуктом. По крайней мере таких элементарных багов и опечаток в документации я не замечал.

anonymous
()
Ответ на: комментарий от CrossFire

Это вроде ещё до покупки было. И дело сейчас скорее не в ресурсах, а в стиле разработки. Нет у них единого вектора развития.

anonymous
()

можно будет словить забавные баги, например при отладке в qtcreator:

&«warning: GDB: Failed to set controlling terminal: \320\235\320\265\320\277\321\200\320\270\320\274\320\265\320\275\320\270\320\274\321\213\320\271 \320\272 \320\264\320\260\320\275\320\275\320\276\320\274\321\203 \321\203\321\201\321\202\321\200\320\276\320\271\321\201\321\202\320\262\321\203 ioctl\n»

x905 ★★★★★
()
Ответ на: комментарий от tensai_cirno

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

zekses
() автор топика
Ответ на: комментарий от x905

На сокет при невыясненных обстроятельствах в рандомный момент переставали приходить датаграммы, как широковещательные, так и отправленые конкретно на данный адрес. Вот просто переставали приходить и всё. Решалось ребиндом сокета. При этом в wireshark'e эти датаграммы было видно, а вот до этого сокета они почему-то не доходили. Под онтопиком всё норм было. Багрепорт не оформлял пока, потому как надо закодить тестовый пример, где это повторяется.

WRG ★★★★
()

Да, несправедлив тот факт, что англицкий текст будет выводится как есть, без \u... Если бы оно выводилось в такой-же нечитабельной форме - то в этом может и был бы смысл (как говорит Тьяго - посмотреть реальное содержимое строки). А тут получается, что англичане в плюсе как ни крути. :)

anonymous
()

Да собственно говоря они уже давно идут в сторону того, что весь текст в программе должен быть на английском. А перевод должен быть выполнен через соответствующие тулзы. Выпиливание QTextCodec::setCodecForTr тому яркое подтверждение.

dnf83
()
Ответ на: комментарий от WRG

чтото подобное я отметил и у себя для tcp и при этом было Qt::QueuedConnection - попробуй сменить, может поможет, хотя это баг конечно, но я пока забил на него

x905 ★★★★★
()
Ответ на: комментарий от dnf83

весь текст в программе должен быть на английском

это запрещено стандартом ?
русские символы разве не в utf8 ?

x905 ★★★★★
()
Ответ на: комментарий от x905

это запрещено стандартом ?

Так о чём тогда эта тема? Не пишите по русски, раз запрещено стандартом.

русские символы разве не в utf8 ?

Там, но с чего это вдруг исходники должны быть в Utf8?

dnf83
()
Ответ на: комментарий от Dendy

Прочитайте тред, он совсем про другую проблему.

Прочитал. Проблема ровно та же, авторы Qt выпиливают из исходного кода всё кроме Latin1. Теперь просто до qDebug добрались.

dnf83
()
Ответ на: комментарий от dnf83

исходный код ни при чём - многократно уже было сказано, что текст может прийти из переменной к исходному коду отношения не имеющей

zekses
() автор топика
Ответ на: комментарий от dnf83

Прочитал.

Плохо прочитал, давай ещё раз (-:

Dendy ★★★★★
()
Ответ на: комментарий от dnf83

Там, но с чего это вдруг исходники должны быть в Utf8?

система в utf8, весь исходный текст в utf8 - с чего это вывод нельзя делать в консоль в utf8 ?

x905 ★★★★★
()
Ответ на: комментарий от ckotinko

в qt utf16

а ну тогда пусть любой вывод в консоль (да и в gui тоже) делают однотипно «\ddd+» - будет очень здорово и все обрадуются
а то ведь вдруг кто A от А не отличит )

x905 ★★★★★
()
Ответ на: комментарий от x905

система в utf8, весь исходный текст в utf8 - с чего это вывод нельзя делать в консоль в utf8 ?

Тьяго настаивает, что выводить кракозяблы в консоль кроссплатформенно. Как будто кроссплатформенность qDebug вообще когда-то было критерием.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

Тьяго настаивает, что выводить кракозяблы в консоль кроссплатформенно

да, это он точно подметил )
кракозябры они всегда кросплатформенны )

x905 ★★★★★
()
Ответ на: комментарий от x905

система в utf8, весь исходный текст в utf8 - с чего это вывод нельзя делать в консоль в utf8 ?

Не переживай. У товарища каша в голове. Он путает кодировку исходника (UTF-8) с внутренней кодировкой QString (UTF-16)

anonymous
()

Note how I also changed QtTest printing of QByteArrays: it used to print each byte hex-escaped and now it prints US-ASCII C-style escaped strings, like QDebug.

Я правильно понял, что он еще и QtTest сломал?

CrossFire ★★★★★
()

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от CrossFire

Я правильно понял, что он еще и QtTest сломал?

Это он считает, что исправил. Этот индус ещё несколько лет назад проталкивал какие-то абсурдные идеи. Результат на лицо. Даже горячие клавиши все поломали.

anonymous
()

Ilya Kotov added a comment - 9 hours ago
qDebug() << qPrintable(QString(«русский текст»)) still prints normal text. I think, this should be fixed too.

Товарищ, не надо так. Нужны аргументы, а не абсурдные предложения.

CrossFire ★★★★★
()
Ответ на: комментарий от CrossFire

Это бесполезно. Я его знаю. Так что пусть потрахается хотя бы.

anonymous
()

Они еще и хоткеи поломали на русском, вредители какието

Наверно они решили что и это тоже было неверно «что работало», а на самом деле не должно

x905 ★★★★★
()
Последнее исправление: x905 (всего исправлений: 1)
Ответ на: комментарий от Dendy

Оно работает только потому что локальная кодировка совпадает с кодировкой файла исходного кода (UTF-8?),

а есть актуальные ОС без поддержки UTF8?

next_time ★★★★★
()
Ответ на: комментарий от EXL

Зато няшный qml запилили. И 11е кресты местами.

anonymous
()
Ответ на: комментарий от anonymous

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

ЯННП, если Ctrl+F работает в обоих раскладках, то что тогда не работает?

CrossFire ★★★★★
()
Ответ на: комментарий от CrossFire

Не работает просто «F», «D» и прочие. Они часто в плеерах используются. Но мне там один упорный доказывает, что так и было. Чёртов английский и расстояния. Так бы я его рожей ткнул в этот баг. Впрочем, у меня подозрения, что баги закрываются под любым предлогом. Реально задолбало воевать за каждый баг.

anonymous
()

Тьяго договорился до странных вещей: «Therefore, full Unicode support was never a supported feature.» Похоже, с этим клоуном проект обречён.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.