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
()
Вы не можете добавлять комментарии в эту тему: топик перемещен в архив.