В общем, пока плюнул на архитектурную чистоту, возвращаю из функции указатель на созданный объект, удаляю по окончание работы.

Попутно узнал и другие интересные вещи, например, что при программном формировании QImage setPixel() - очень затратный по времени метод. Возможно, таки откажусь от QImage на стадии генерации изображения и буду работать просто с байтовым массивом, а в QImage запихаю уже готовый результат перед записью в файл.

Ну это "внешний" способ. Хотелось бы надёжную диагностику в Runtime, чтобы при запуске было понятно, кто виноват - программист, тот, кто дистрибутив формировал или вообще кто-то третий. А то, грубо говоря, программа тащит Qt, Qt тащит libpq, libpq тащит libiconv и ещё бог весть что из библиотек, вплоть до Microsoft Redistributable... а исход один, "driver not loaded".

Как там в анекдоте про Папу Римского - несправедливо!

P.S. Приведённый пример с драйверами - всего лишь пример, есть и другие похожие ситуации.

Добрый день.
Как все знают, QLibrary::load() может не сработать, и в errorString() при этом можно увидеть сообщение "Не найден указанный модуль".
Проблема в том, что в роли "указанного модуля" может выступать не сама загружаемая библиотека, а одна из библиотек, от которых она зависит.
Можно ли как-то расковырять информацию о том, какая именно библиотека второго уровня не найдена?

Я даже готов для этого наковырять платформозависимые костыли для Linux и Windows. Если это поможет, конечно.
Куда копать?

Добрый день.
Я пишу функцию (точнее, конечно, метод класса), программно рисующую в объект QImage (больших размеров, например, 6240x4160 пикселей). Объект должен быть потом доступен извне (для сохранения в файл и не только).
Думаю, как лучше оформить эту функцию.

Первый вариант - создать объект QImage внутри функции и вернуть его. Могу я в этом случае полагаться на эффективность механизма COW, ведь формально говоря, внутри функции будет один объект, а снаружи другой?

Второй вариант - создать объект извне и передать в функцию неконстантную ссылку на него. Тогда вопрос сводится к тому, смогу ли я внутри функции поменять размеры уже сконструированному изображению? Я вот конструктор с width и height вижу, а отдельной функции изменения размера - нет.

Третий, заведомо работающий и самый простой - выделить в функции объект динамически и вернуть указатель на него. Но, разумеется, надо не забыть его потом удалить. Ну и насколько я понимаю, в современном C++ такое считается моветоном?

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

А ещё более простенькое? Где никакого QtLocation нет, обычный Hello world? Тоже виснет?

МОЖНО. Только надо предоставить получателю продукта альтернативный способ замены вашей Qt на другую совместимую.
Один из вариантов - приложить архив с объектными модулями. Заказчику он, конечно, 100 лет не упёрся, но можно ему так и сказать - "этот файлик на 40 метров нужен для соблюдения лицензии, точка". В большинстве же более-менее сложных проектов динамическая компоновка тупо проще и компактнее, тут ты прав.

Да, я помню, что этому комментарию 4 года. Но это один из "мифов про LGPL", которые до сих пор живучи. Вот буквально сегодня приходилось спорить с оппонентом, заявлявшим, что "по Qt с LGPL нельзя выпускать коммерческое ПО".

Вместо Visual Studio, скорее всего, достаточно поставить соответствующий Microsoft Redistributable 20**.
Если и это чересчур, откажитесь от майкрософтовского компилятора и пересоберите программу в MinGW.
Правда, у вас ещё и PostgreSQL... Тогда, возможно, libpq.dll от постгри и то, что она за собой тянет, тоже придётся пересобрать в MinGW (сразу скажу, этого я не делал, ставил постгрю целиком).

Да, при тех условиях, которые хочет автор, самое простое, наверное, - это запускать всё через батничек, в который добавлять строчку с PATH перед вызовом EXE.

DLL является частью процесса, который её загрузил, выводы делай сам.

Если сам пишешь - то почему принципиально, чем вариант с DLLями не устраивает? Надо, чтобы программы могли запускаться не только из оболочки, но и самостоятельно? Если да, то это в принципе аргумент, хотя и тут можно извернуться.

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

Критично, что именно другой ПРОЦЕСС?

Я в своё время делал MDI-отображение нескольких программ в одном MDI. Но эти программы были реализованы как DLL (Windows) и SO (Linux), то есть специально написаны под данную оболочку. Грузились по запросу пользователя, из списка, список формировался динамически. Процесс был один. Многопоточность, естественно, в программах можно было организовать своими силами.

Если нужен MDI над уже написанными программами, у которых есть свой GUI, без перекомпиляции - очень сомневаюсь, что такое возможно вообще. Над консольными-то можно написать обёртку через QProcess и парсить их вывод, это, как ни странно, проще...

Убедительная просьба - НЕ НАДО делать скриншотов из кусков своего кода! Для этого есть тег [ code ].
Когда вы превращаете код в графику, он, во-первых, замусоривает БД форума, во-вторых, его невозможно найти поиском.

Это легендарное сообщение, которое может появляться по куче причин.
Его у тебя точно сам Qreator выдаёт, а не проект, в нём собранный?

Удваиваю. Конец мая, на гите всё по-прежнему доступно.

Отдельное спасибо qtkoder777 за апанье темы, хотя добивался он видимо, противоположной реакции ))

Я думаю, что это не "помечтать", а в итоге самый толковый способ.

Только в GUI thread, думаю, надо хранить статус "загружено - загружается - не загружено". Чудес-то не бывает. Если юзер захочет быстро попереключаться туда-сюда, надо во время загрузки показывать что-то типа "данные загружаются", а если эти данные могут измениться прямо во время работы - возможно, и добавить в инфо-окно кнопку "Обновить", которая снова дёрнет на запуск нитку загрузки. Просто при переключении между окон нитку не дёргать, пусть программа показывает ранее загруженные данные. Иначе вся эта многопоточность быстро доведёт программу до цунгундера. Для особо бестолковых любознательных можно при последующих переключениях подсвечивать рядом с кнопкой "Обновить" надпись что-нибудь типа "Данные могут быть неактуальными", если речь действительно идёт не про файлы, а про данные реального времени...