Спасибо!

Добрый день!
Обычно пути к внешним библиотекам задаются (при необходимости) в файле проекта: и погнали.
А есть ли возможность как-то добавить путь в эту переменную в параметрах вызова qmake? Чтобы файл проекта не править под конкретную систему.

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

Вам или организации?
Если первое - интересно послушать аргументы.

А что уж тогда не в канонiчном КОИ8-Р? 

Про clang не подскажу, но корень ваших проблем - здесь. Не надо так делать. Да, часть проблем решается через принудительное задание кодеков и др., но рано или поздно косяки вылезут.

Я в своё время прогнал исходники через enca, теперь там только UTF-8.

(Ещё более правильный путь с точки зрения Qt - вообще не допускать в исходниках никаких нелатинских символов, русские и прочие строки держать в файлах переводов. Но для проекта, который никогда не выйдет за пределы России, это сильно избыточный подход, да.)

К получению прибыли вопрос ТСа отношение имеет примерно никакое, не надо вводить людей в заблуждение.
Загвоздка исключительно в том, что вы будете отдавать законному получателю вашего продукта. Если вы пользуетесь LGPL-сборкой, то читать надо саму LGPL, а не то, что пишут на qt.io перед кнопкой "Скачать" (там упрощённые формулировки для менеджеров и прочих ЛПРов). А сама LGPL требует именно то, о чём я написал выше - дать возможность получателю менять саму библиотеку. Пути выполнения этого требования разные - либо исходники, либо объектники, либо динамическая компоновка.
Если требования LGPL не устраивают, и вы отдаёте продукт на сторону - наоборот,нужна коммерческая версия, вне зависимости, получаете вы прибыль или нет.

Насколько критично именно Visual Studio? Для MinGW задача решённая, если что.
И на Win95 я бы особо не рассчитывал, особенно в случае майкрософтовского компилятора, нужный ему рантайм уже даже под XP запросто может не запуститься (вы можете собрать Qt статически, но при этом библиотеки от майкрософта придётся тащить всё равно).

Далее, надо смотреть, какую вы лицензию используете и распространяете ли продукт за пределы своей фирмы. Если вы используете LGPL-сборку Qt, надо дать возможность получателю вашей программы возможность замены Qt (я в курсе, что ему это, скорее всего нахрен не упёрлось, но лицензия требует). То есть если сборка статическая - надо будет дать либо исходники, либо объектные файлы (последнее, наверное, легче). Ну либо покупать коммерческую лицензию на Qt, да.

Под майкрософтовский компилятор - возможно. Для MinGW у меня даже инструкции (лично написанные) есть.

Добрый день.
Пишу я, значит, текст, и прямо по ходу набора получаю предупреждение: "label at end of compound statement". Довольно долго соображал, в чём дело. Потом понял: я просто влепил метку в switch-case, а логику её обработки написать ещё не успел.
Qt Creator 6.0.0, Manjaro KDE. Clang Code Model включена.
Нет ли какой настройки, чтобы предупреждения появлялись не сразу, а через какой-то таймаут, если ошибка сохранится? Потому, что оно накладывается прямо на текст программы и отвлекает от кодирования. Или единственный путь - отрубить эту Clang Code Model нафиг? Тоже жалко, так-то штука полезная.

Добрый день.

Мне приходится обрабатывать текстовый файл, в котором смешаны разные кодировки (частично UTF-8, частично ANSI - для русского языка это cp1251). Как ни странно, это MPB - файл резервной копии достаточно известной и пользующейся уважением программы MyPhoneExplorer, пожалуй, лучшего решения для извлечения и восстановления контактов, сообщений, истории вызовов и кое-чего ещё с андроид-телефонов на ПК. Почему немецкий автор сделал такой странный контейнер, я не знаю, но формат есть и довольно популярный. Соответственно я в DoubleContact его поддерживаю.

Я использовал QTextStream::setCodec(), вызывая его прямо посреди файла, при переходе к следующей секции. На очень старых Qt - <4.8 - при этом сбивалась позиция в файле (подозреваю, из-за несовпадения длины символов в разных кодировках). В Qt 4.8.* и Qt5 вроде бы проблема решилась, но сейчас, когда я стал читать большинство секций файла MPB, а не только некоторые, опять начались артефакты.

Вопрос, собственно, в следующем. Насколько "законно" вызывать QTextStream::setCodec() посреди чтения файла? В документации я нашёл только такую оговорку:


Но это, как я понимаю, только про сетевые сокеты?

Или в этом случае надёжнее вообще отказаться от QTextStream и читать весь файл как набор байтов, а потом уже разные секции перекодировать разными кодеками из QByteArray в QString? Тогда и от readLine придётся отказаться и ловить границы строк самому...

P.S. Я в курсе, что в Qt6 начали крестовый поход против QTextCodec и замену его "обезжиренными" классами, работающими только с юникодом. Довольно странная позиция, учитывая. что из реальной жизни неюникодные кодировки никуда не ушли и не уйдут ещё скоро. Именно поэтому поддерживать Qt6 я пока не тороплюсь, в глубине души теплится надежда, что корпоративные клиенты их образумят (а не образумят - придётся тащить в свои проекты libiconv). Но это вопрос отдельный, мне бы с тем, что есть, разобраться...

А что, собственно, понимается под библиотекой?
Исходники проекта остались? Или именно они и пропали?

Несколько раз собирал статически Qt для Windows, как 4, так и 5, с помощью MinGW.
Потом захотел посмотреть, что будет, если сборку убрать в другой каталог. И всё заверте...
Qt4: qmake не может найти uic.
Qt5: грабли с mkspec.
Я правильно понял, что в собранной Qt захардкожены абсолютные пути, и перенести в другой каталог без перекомпиляции не получится?

Не то, чтобы мне без этого прожить нельзя, но если моё наблюдение верно, это надо будет учитывать. А то я тут мечтал деплоить собранную Qt на другие машины, получается, её надо будет распаковывать в строго определённое место...

О, баттл! 

Но на самом деле ТС сам себе правильно ответил, что

 

Я вот не уверен, что из объяснений я правильно понял задачу. Но если вкратце - я бы прикрутил ко всему этому сбоку некий ChannelsAndFramesManager, который и следит за целостностью всего описанного выше безобразия. И все запросы на изменения - строго через него.

Сигналы/сообщения могут помочь в его организации, но не вместо него.

Это не единственный подход. Но я бы сделал так.

Если за полтора месяца тема сохранила актуальность - вставлю 5 копеек.

Вы очень ошибаетесь, он принципиально легче. У Qt3 и Qt4 есть множество несовместимых в принципе мест.
А с Qt4 на Qt5... У моего редактора контактов исходники совместимы и с той, и с другой, и на весь проект буквально несколько условных компиляций (навскидку вспоминается вынос QStandardPaths из QDesktopServices).

Разумеется, есть оговорки. Если из проекта на Qt4 до сих пор не выкинут Qt3Support, то его выкидывание - это первый и необходимый шаг к переносу. А дальше можно добавить строку условного добавления модуля QtWidgets в файл проекта (если проект гуёвый) и начинать гонять сборку с Qt5 и ловить глючки...

О-оо!
Возможно, так даже лучше будет. Доживу до выпуска 0.3.0 - попробую этот вариант.