- =A=L=X=
- Постоялец
Пару месяцев назад я лениво начал осваивать Qt и столкнулся с явлением о котором ранее не задумывался - о собственно сабже.
Если кто не в курсе быстро поясню в чём косяк:
LGPL если совсем вкратце обязует линковаться к открытой библиотеке динамически чтобы соблюсти принцип "свободное должно оставаться свободным".
Например у пользователя программы должна оставаться возможность заменить открытую библиотеку новой версией и запустить как ни в чём не бывало.
И вот тут у C++ возникает большая проблема - если новая библиотека изменить раскладку в памяти хоть одного объекта, а в ООП программировании мы это делаем постоянно и не напрягаясь дорабатывая и апгрейдя, то ваш несвободный код станет невалиден т.к. без перекомпиляции просто будет лезть не в те места объектов в какие нужно.
В Qt для ликвидации этой проблемы используется прослоечная техника - все объекты "для клиентского кода" на деле являются смарт-пойнтерами в стиле pimpl и никогда не содержат ничего кроме этого указателя и эта конфигурация будучи задана в очередной мажорной версии библиотеки никогда более не меняется. Мы всегда работаем с объектами Qt через такие прослойки.
Тогда действительно поменяв имплементацию надёжно скрытую за pimpl можно еще о чём то говорить. Так и только так.
Так что если вы соберётесь писать ООП-либку на C++ с расчётом выпустить её под лицензией LGPL - одумайтесь, ибо грядёт.
как-то читал простыню комментов на хабре под Qt статьей, смысл обсуждения и статьи заключались в том, что LGPL это нифига не просто линкуйтесь динамически и используейте pimpl, и как бы велом про использование кода и вообще, мол, покупайте лицензию Qt коммерческую, а то ибо грядет.
MAMOHT-92
> LGPL это нифига не просто линкуйтесь динамически и используейте pimpl,
Плюс еще большие проблемы с мобильными платформами где закрытые инсталляторы и потому просто заменить dll-ку вообще непросто.
Но это не вина самой LGPL, а этих платформ, но из-за таких проблем действительно проще бывает купить лицуху.
Человечество вечно создает себе проблем на ровном месте, как тот хохол на велосипеде, сующий ветку себе в колеса.
Просто интерфейс от имплементации отделять надо. Можно делать сишный интерфейс, как вариант. А что там внутри юзера не должно волновать.
PANDA
> Можно делать сишный интерфейс, как вариант.
Это самый простой и проверенный временем вариант, но он не ООП.
=A=L=X=
>но он не ООП.
Я бы поспориль.
nes
> Я бы поспориль.
Ну речь всё-таки в рамках плюсовского ООП-а.
=A=L=X=
> Ну речь всё-таки в рамках плюсовского ООП-а.
Ну можно просто делать классы, у которых нет ни одного публичного поля. Тогда будет полностью в рамках плюсовских классов.
Dmitry_Milk
> Ну можно просто делать классы, у которых нет ни одного публичного поля.
Нельзя. Если сменишь состав полей - data_layout разъездится.
Можно поступать хитрее - сделать конструктор private и заменить его на фабричную функцию, возвращающую unique_ptr. Это будет почти как pimpl - но с явной косвенностью.
А ещё с таблицой виртуальных функций есть проблемы, чтобы их не было, все виртуальные методы следует сделать protected, чтобы из пользовательского кода напрямую их нельзя было звать.
Panzerschrek[CN]
> Если сменишь состав полей - data_layout разъездится.
Так тебе, как пользователю библиотеки, какая разница, какой там у ее внутренних объектов layout? Ты же к этим полям никогда сам не будешь обращаться (да, надо еще исключить возможность инлайна).
UPD. А, все, понял, проблемы будут при использовании объектов по месту, а не в куче. Ну тогда да, вариант с закрытием конструктора и реализацией фабрики, возвращающей unique_ptr действительно кажется красивым рещением.
Надо, имхо, внедрить pimpl в язык, чтобы было не так калечно и с дублированием кода, а по уму.
Объявляешь класс как virtual class и у него сразу первое поле - vtbl, в .h можно только декларации методов предоставить, а вся подкапотня уходит в кишки .cpp и о ней внешнему коду вообще ничего не надо знать включая размер.
Т.е. работать с такими классами можно как раз только через указатели. Что-то среднее между pimpl и COM.
> Так что если вы соберётесь писать ООП-либку на C++ с расчётом выпустить её под лицензией LGPL
Выпускайте под MPL-2.0 или CDDL
Тема в архиве.