Не заметил дату. Жаль.

Скорее всего, он так и сделал, судя по молчанию...

Вот это поворот! Вижуал Студия научилась читать "вражеский" формат? Ах да, оказывается, это функция самой qmake. Тогда не так интересно.

А по сути вопроса - можете выложить образец файла .sln, чтобы оценить сложность задачи?

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

Попутно узнал и другие интересные вещи, например, что при программном формировании 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 выдаёт, а не проект, в нём собранный?