Явным образом LGPL не запрещает статическую линковку. В тексте лицензии вообще нет упоминания ни о каких линковках. Но там есть следующий момент. Должна существовать возможность связывания вашего ПО с новейшей версией программы или библиотеки, охваченной LGPL. 

Что для этого сделать написано в пункте 4d. Под циферкой 1 речь идёт как раз о той самой динамической линковке:


А вот под циферкой 0 есть кое-что ещё, что пригодится как раз при статической линковке. Можно предоставить исходный код вашего приложения или объектный код, в таком виде, чтобы обеспечит возможность линковки с другой версией библиотеки.

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

Но если стоит вопрос "Позволяет ли LGPL статическую линковку?", то ответ "Да, конечно." Только исходный код придётся открыть. Ну или вот этот спорный вариант с объектным кодом использовать...


Забавные у тебя примеры. Windows-only программы сравнивать с программами, написанными под кросс-платформенную либу? Смеёшься?


Спасибо, что просвятил.  


Меня это мотивирует не достаточно. Скажем так - есть дела и поважнее.


Я статически ни разу не линковал. Но думаю, что ответ, скорее, отрицательный.

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

Qt не сильно предназначен для создания программ уровня "привет мир". Основное - создание бизнес-приложений (например, Adobe Photoshop). В таких приложениях размер библиотеки 10-20 МБ не считается чем-то экстраординарным. Зато очень ценится возможность быстро написать основную часть программы не заморачиваясь на создание кнопочек/окошек, а так же при необходимости портировать на другую платформу.
Например, начинающий программист вряд ли оценит то, что интерфейс для работы с таблицей в SQL БД делается всего в 10-20 строк. Ну не надо ему это...

Gtk+ пытается в Windows работать точно также как и Qt - получает через системный вызов битмап с отрисованным контролом (или же его части) и блитит его на окно. Но так как почти всем плевать на поддержку win32-версии gtk+, то до ума рендеринг системной темы не доведен (например отсутствует анимация fade in/out в Vista/7).

Это ваше Qt использует MOC, что не является нативными сями, плюс лицензия.
wxWidgets действительно использует нативные контролы и весит много меньше. Хеломир меньше метра собрать реально, возможности сопоставимы с кт.
Так что именно по этому его и выбираем!

Ах да, хочу передать привет тем людям, кто считает, что .net - это нормально. Вас проклинают те люди, которым из-за вашей проги с одной кнопкой нужно тащить 30 метров этого уродства.

Это сообщение отредактировал(а) Randajad - 10.6.2012, 16:45

основной плюс при выборе Qt - это документация (и онлайн и асситент интегрированный в creator).


=) после определнного момента перестаёшь обращать внимание не то что на чистоту языка, а вообще на язык. Любой необходимый базис нового языка изучается за неделю на ура. Так что это скорее предрассудок. Или вы про инструментарий (компиляторы)? В таком случае даже "чистый спп" (например 2011) не всеми компиляторами поддерживается в полной версии.


А в чём проблема с лицензией.
Если пишешь для себя, то спокойно юзай опенсорс вариант.
Если ты продаёшь свой продукт (и продаёшь успешно) то спокойно можно отстегнуть за удобный инструмент (ты же по сути тоже за свой труд хочешь деньги получать).


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

MOC можно приделать далеко не к любому IDE. Qt становится невозможно юзать без перехода к другому IDE.
Конечно можно отстегнуть, наверное так и надо делать. Слово экономия нам чуждо. Действительно, сейчас все богатые, а в компьютерах харды уже на террабайты и памяти гигабайты. 
Реализуя какой-нибудь алгоритм в своем приложении вы так же мыслите, позвольте поинтересоваться? 

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

Лицензия Qt не запрещает продавать свой продукт, сделанный из опенсоурс библиотеки. Даже не нужно, чтобы ваше приложение имело бы такую же лицензию. Главное - не изменять саму библиотеку.


А надо ? Есть IDE лучше, чем QtCreator под линукс и студия плюс Qt-шный аддон для Windows ?


Вот полностью согласен (никогда не понимал эту "определённую группу"). Randajad, вот скажи, неужели ты из двух программ, решающих  примерно одинаковые задачи (например - месенджеры QIP и PSI), выбираешь исключительно по тому, сколька каждая "весит" ? Разве не удобство, функционал, неглючность и т.д. и т.п. ?

Randajad, ты не о том говоришь.
первый и основной минус кути в том, что она не может без moc`а. а тот в свою очередь, не дает кодить в привычном для меня стиле, ибо запрещает шаблоны.
второй минус(на мой взгляд) - размножаются ###кодеры.

Randajad, позволь вопрос - ты зарабатываешь программированием? Если да, то за свой труд ты бы хотел получать деньги? Почему же давит жаба оплатить труд других программистов, результатами которого ты пользуешься для своего заработка?
 Да и касательно использования опенсор для своей коммерции borisbn уже сказал. Просто до версии 4.5. наша фирма именно коммерческую лицензию покупала - вот я и по инерции - но суть таже.


Зависит от "контекста" задачи (ТЗ, сроки выполнения и т.д.)


разве? Спокойно юзаю шаблоны по мере необходимости.

Это сообщение отредактировал(а) _GRIN_ - 11.6.2012, 23:37

значит твоя необходимость мала.

Вполне возможно, но мне хватает (шаблонные классы, шаблонные методы, шаблонные функции).

boostcoder, а можно пример кода (не зависимого от какой-либо библиотеки) содержий шаблон, который QtCreator не осилит?
Признаться очень интересно посмотреть.

Это сообщение отредактировал(а) _GRIN_ - 11.6.2012, 23:18

все-таки который MOC не осилит

закодь любой класс наследник QObject, и сделай его частичную специализацию основываясь на компайл-тайм типах/константах. тут-то moc скажет, что он о тебе думает 

Добавлено @ 23:33
хотя я удивлен тому, что кто-то этого не знает.
признаюсь, с использованием Qt не кодил уже больше двух лет. возможно moc пофиксили... но очень сомневаюсь. иначе его бы пришлось научить специализировать шиблоны и генерить GIMPLE. а это наверное половина компилятора.

Добавлено @ 23:37
а в качестве сигналов/слотов, он уже позволяет использовать шаблонные методы/функции/функциональные_объекты/лямбды?


Это сообщение отредактировал(а) boostcoder - 11.6.2012, 23:38

такой пример (из одного моего работающего на местах) проекта подойдёт:


тут правда шаблон нужен только в методе setPrivate() и там только конструктор шаблона с параметрами вызывался.
Но ничего другого под рукой нет к сожалению.

З.Ы. Я всё ещё достаточно плохо знаю кьют. Так что действительно посмотрел бы на ваш код илюстрирующий проблему.
Единтвенное ограничение, которое я знаю - это запрет множественного наследования qobject классов.

Добавлено через 5 минут и 11 секунд

alexvs11, ваше замечание абсолютно верно =).
Мос имеет свои ограничения, и свои плюсы (сигналы слоты).
Сам по себе кьют использует moc для сигналов слотов. Если эти плюсы не нужны, то можно спокойно забить на moc и использовать кьют без генерации moc-файлов как обычно - просто не объявляйте Q_OBJECT (правда и без сигналов-слотов останетесь)

так как посылать/принимать сигналы могут только наследники QObject (вроде не только, но там с какими-то извращениями), то из этого списка вопрос только о шаблонных методах
http://doc.trolltech.com/qq/qq15-academic.html
думаю, что и сейчас невозможно


видимо это достаточно редко требуется на практике?