Comments 70
Другое дело, что полностью отказываться от него никто не будет в здравом уме…
Да и до 20-го стандарта не долго осталось уже.
Кстати, если не ошибаюсь то группа занимающаяся стандартом рассматривает рефлексию в C++17? Или я что-то путаю?
Смысл всего этого был в том, чтоб напрямую линковать CS библиотеки к программе, т.е. не нужен qmake/moc, компилятор поддерживающий стандарт все это сделает сам. Идея отличная, насчет реализации не знаю. CS так и не собрался попробовать.
Хотя я так и не нашел информации по *.ui, т.е. в Qt (если я не ошибаюсь) moc так-же транслирует *.ui файлы интерфейса в *.cpp/*.h.
Хотя я так и не нашел информации по .ui, т.е. в Qt (если я не ошибаюсь) moc так-же транслирует .ui файлы интерфейса в .cpp/.h.
Этим занимается не moc, а uic. Вообще ui файлы можно динамически грузить в приложение без трансляции в h-файлы.
Нужно будет попробовать его полноценно с QtCreator связать.
Смотрите код CS, они там его и реализовывали.Не кормите тролля. Он и сам прекрасно знает это и может нагуглить, просто ему скучно, пообщаться хочется.
Кстати, если не ошибаюсь то группа занимающаяся стандартом рассматривает рефлексию в C++17? Или я что-то путаю?17-й стандарт был принят в марте, там нет рефлексии. Обещают к 20-му.
На самом деле, в CS продумали довольно много мелочей, которые множество недостатков Кьюта устраняют нативно из коробки без оверхеда и потери информации о типах, плюшки вводят нативные. Рефлексия там на макросах и шаблонах. Но вот, что-то с разработкой у них как-то слишком тухло. Пулл-риквесты рассматривают по полгода, к сожалению. Закрылись от мира, сидят своей кучкой что-то кодят, только релизы синхронизируют с гитхабом, когда им вздумается. А задумка изначально интересная…
Я просил код не потому, что это сделать нельзя, а потому что это такие же костыли. При этом, если у Оливера получилось сделать Qt без moc почти также со стороны производительности, времени компиляции, бинарной совместимости, то у CS получилось откровенное хреново все.
Может быть позже, когда это все будет в стандарте, я полностью соглашусь с мнением, что moc можно выбросить на помойку, но сейчас замена одних костылей на другие костыли едва ли принесет хоть какую-то пользу.
напрямую линковать CS библиотеки к программе, т.е. не нужен qmake/moc
Причем здесь линковка, qmake и moc? Идея CS — убрать moc, то есть генерацию исходников с кодом метаинформации на основе других исходников, использующих макрос Q_OBJECT. Идея-то, в целом, хорошая, позволит, например, использовать шаблонные классы с QObject, но на текущий момент она решается точно таким же костылированием, что и moc. При этом, еще и выдает намного меньшую скорость.
Причем здесь линковка, qmake и moc?
А при том, что программу на Qt нельзя просто так взять и (примерно):
g++ -I/usr/include/qt5 prg.cpp -lqt5
Потому-что moc еще должен сгенерировать того, чего нет. А так как в CS рефлексия реализована чисто на C++11, то можно просто «заинклудить» и «прилинковать» что нужно.
Как я уже писал в соседних сообщениях, это все будет хорошо, если будет в стандарте. Пока у CS есть и обратная сторона:
1) время компиляции
2) размер получаемых файлов
3) производительность
и самый важный косяк
4) нет бинарной совместимости
2) размер получаемых файлов
А у Qt лучше что-ль? Вот была у меня программа которая использовала WebView, так этот единственный модуль тащил за собой (из-за того что слинкован с оными) совершенно ненужные вещи, такие как QtSensor, QML, Quick и еще что-то, чего я уже не помню.
В Qt Lite начались какие-то подвижки в сторону разрешения подобных вещей, но опять-же это началось относительно недавно.
Да и вообще, есть же LTO. Можно сразу разрабатывать с оглядкой на него.
4) нет бинарной совместимости
А можете пояснить где ломается ABI? Если у них рефлексия вся в заголовочных файлах (макросы и другая магия), то на библиотеки вообще плевать, оно все static получается.
А у Qt лучше что-ль?
Размеры бинарников Qt находятся на адекватном уровне. QtCore где-то в 3.5 раза больше libstdc++, но и предоставляемый функционал намного шире. Собранного CS у меня нет, но, вангую, из-за
Соглашусь, конечно, что иногда нужный функционал лежит где-то не там, и брать здоровенный модуль ради одной нужной функции очень не хочется. Но это проблема всегда будет преследовать большие проекты — что и куда класть, как разделять логику модулей.
Да и вообще, есть же LTO. Можно сразу разрабатывать с оглядкой на него.
Ну Qt с LTO собирается.
А можете пояснить где ломается ABI? Если у них рефлексия вся в заголовочных файлах
Если мы инлайним шаблонный код в сорцы нашей либы, то любое изменение каких-либо задействованных структур данных приведет к полной перекомпиляции либы, которая станет несовместимой с предыдущей реализацией. Конечно, есть решения, но это дополнительная сложность. Почитать, например, можно тут.
magic_get Рефлексия без макросов, правда только для POD типов.
Ну, так-то усложняет. Добавляет ещё один сторонний этап сборки
Усложнение для кого/чего, разработчика или компьютера? Если для компьютера, то какая разница, если для разработчика накладные расходы на автоматический запуск qmake в IDE равны нулю?
Только если типы объектов известны в compile-time.
Приведите реальный пример.
Так про связку C++ и QML в документации написано, что functor-based подход в этом случае не работает.
ещё один этап сборки
Звучит так, словно это что-то невероятно сложное. Но на фоне того, как зачастую устроена сборка большого C++ проекта, запуск qmake — это капля в море.
Это не так. (x+1) этапов сборки больше чем (х) этапов сборки, что добавляет соответствующие потенциальные проблемы в виде багов moc'a и moc-aware систем сборки.
Ну это звучит так, как будто вы докопались к формулировке. В том же cmake вся проблема со сборкой решается банально одной строчкой:
set(CMAKE_AUTOMOC ON)
Насчет именно этапов: я готов согласится с автором, что если перенести moc на макросы и шаблоны, вычислительных ресурсов будет потрачено больше (инстанцирование шаблонов). Так что в некотором роде можно сказать, что с moc это даже проще.
Когда я увидел, как CopperSpice использует этот аргумент против Qt, то потратил 5 минут на то, чтобы исправить это с использованием variadic-макросов из стандарта С++11.Это в какой версии появилось? В 5.8?
Когда-нибудь задумывались почему qobject_cast настолько быстрее, чем dynamic_cast?И почему?
У меня, как у упёртого линуксоида, к Qt одна "претензия", и то не совсем к нему. Извините за сумбурность, это и в беседе-то сложно объяснить.
На Линуксе давно надо навести порядок в области создания десктопных юзерских программ. Qt отлично подошёл бы в роли главного, "стандартного" фреймворка для создания гуя. А Python для Линукса — де факто главный язык пользовательского софта. Но вот эта конструкция с moc и генерируемым кодом создаёт сложности при попытке привязать Qt к другому языку. В частности, Qt для Python сообщество не осилило — "народный" проект PySide остановился на Qt4, замерев вместе с Nokia, которая его курировала. Остался только PyQT, который выпускает коммерческая фирма. Он идёт под лицензией GPL или коммерческой за 500$. И вот смотрите, что получается:
- Опенсорсники рады, но не все. Ты можешь хотеть выложить свой код под MIT или вообще PD, но облом. Мало того, в одну программу нельзя юридически включать PyQT и коммерческую библиотеку. Есть конечно способы извернуться, да и в основном всем просто пофиг, но всё равно неприятно: ты хочешь потрудиться на благо сообщества, а вместо этого юлишь между законами как Остап Бендер.
- Корпорации обычно рады, им эти 500$ ничего не значат.
- А вот стартапы в полном пролёте.
Именно мелкие стартапы не сумеют заработать на софте под GPL. Если пара человек захотят попробовать написать коммерческую софтинку, то они не будут сходу для первой версии покупать лицензию за 500$, a возьмут другой фреймворк. А ко второй, когда стартап поймёт, что дело двинулось, они может и могли бы выделить 500$, но уже привыкли к тому, что у них есть. В результате мелкий коммерческий софт под Линукс написан кто во что горазд: С++/Qt, Python/Gtk, Go/wxWidgets, NodeJS/(какой фреймворк? ручками нарисую!). Свобода выбора, конечно хорошо, с точки зрения разработчика. А вот с точки зрения пользователя хочется уже устаканивания всего этого зоопарка в какую-то единую, одинаково работающую и одинаково глючащую систему. Чтобы не приходилось в ответ на вопрос, "а умеет ли Линукс HiDPI? Экраны Брайля? Скины? Чтение с экрана?" переспрашивать "А какими именно программами будете пользоваться?"
Самое обидное, что эта проблема созрела ровно настолько, чтобы быть проблемой, но ещё никто не хотел взяться за её исправление. Большинству достаточно того, что есть. А в глобальных размышлениях о судьбах Линукса они не участвуют. Поэтому, хотя Линукс и переходит понемногу на Qt, серьёзного сдвига и на горизонте не видно.
TL:DR — GPL это хорошо, но ключевые библиотеки Линукса должны быть под более свободной лицензией, иначе не видать нам стандартизации интерфейса.
Про PySide2 слышали?
https://github.com/pyside/pyside2
Офигеть. Нет, не слышал. И вокруг меня — никто не слышал. Это и удивительно. Сейчас буду изучать, чего там есть/нет. Но один только факт, что его нет в главрепе Арча, уже смущает. Значит, сколько-то известного софта на нём тоже нет.
Он не так давно (относительно) разрабатывается, но разрабатывается он официально разработчиками Qt, поэтому стоит ожидать, что проект не забросят как первый PySide.
Да, сейчас планируется вернуть PySide в состав Qt, чтобы он был доступен "из коробки" в официальных инсталляторах. Я как раз забыл об этом рассказать в статье про roadmap. Будет доступен как в Open Source версии, так и в коммерческой (включая поддержку).
Разработка ведётся не совсем внутри Qt (первый пост от товарища Кнолла), но с участием, да.
GPL — это средство обороны открытых проектов от воровства. Как и любое средство обороны, применять его нужно умеючи, доставать в крайнем случае, и не размахивать направо и налево. GPL — лицензия для конечного софта, препятствует явлению в мир множества "Антивирусов Бабушкина". Но для ключевых библиотек Линукса — это действительно проблема.
Из практики — есть в интернете приложение под GPL (сейчас уже очень давно не развивающиеся), которое для своей работы требует одну исключительно закрытую и сильно платную библиотеку. Без этой библиотеки работать ничего не будет, так как она используется в основных алгоритмах.
Вот вопрос, да, приложение под GPL, но фактически им пользоваться нельзя даже если сильно платная библиотека у вас куплена.
Даже если пользоваться им подпольно у себя, то сделать форк и выложить его уже не получится, будет мешать хвост коммерческой библиотеки (ее то под GPL вы не выложите, а надо, так как GPL вирусная).
А будь приложение под LGPL или MIT/BSD/Apache, то таких проблем бы не было, но GPL банально известнее и для человека, который в лицензиях разбираться не хочет куда проще поставить шильдик GPL.
Не понимаю, почему из-за GPL нельзя пользоваться ПО. Вот стоит у меня GNOME и я им пользуюсь. Не понимаю, как GPL мне может это запретить или ограничить.
мешать хвост коммерческой библиотеки
Как она может мешать, если изначальная версия программы написана с пользованием этой библиотекой?
Теперь пойдем с конца. Пусть я доработал эту программу и хочу распространять форк. По условиям GPL я должен и зависимости под GPL распространять, но код использует коммерческую библиотеку, делая такое распространение невозможным.
Аналогичную логику можно применить и к оригинальному автору, те возникает вопрос, могу ли я вообще легально использовать эту программу на условиях GPL.
У GNOME все зависимости либо под GPL либо под совместимыми лицензиями, те которые могут автоматически перелицензироваться под GPL при их использовании.
Теперь пойдем с конца. Пусть я доработал эту программу и хочу распространять форк.
Пожалуйста. Вы берете код распространяемый по GPL. Модифицируете, изменения лицензируете под GPL. Вот и все, ничего не нарушено. Можете распространять виде тех же исходных кодов.
Аналогичную логику можно применить и к оригинальному автору
Автор защитил своё право, на написанный код. Более того, автор позволил изучить его код, что дает вам возможность написать новый код с нуля и распространять на любых условиях.
Аналогичную логику можно применить и к оригинальному автору, те возникает вопрос, могу ли я вообще легально использовать эту программу на условиях GPL.
GPL где то накладывает запреты на использование готовой программы?
Мне кажется, что Вы путаете GPL и LGPL, в которой сказанное вами разрешено.
Вы упорно игнорируете тот факт, что неотъемлемым компонентом обсуждаемой программы является проприетарный код, распространять который под GPL невозможно.
Получается вы считаете, что GPL позволяет линьковаться с закрытым кодом без нарушения GPL и без распространения GPL на закрытый код? Если это так, то в чем же тогда вирусность GPL?
А где GPL мне как автору кода запрещает линковаться с закрытой библиотекой? Вирусность заключается в использовании gpl библиотеки с не gpl приложением.
Вы упорно игнорируете тот факт, что неотъемлемым компонентом обсуждаемой программы является проприетарный код, распространять который под GPL невозможно.
Если человек получил такую программу, то у него уже есть эта библиотека в том или ином виде. Почему он не может пересобрать GPL код и слинковаться с тем же экземпляром библиотеки? Можно библиотеку подгружать в рантайме и тогда всё будет чисто.
У автора кода все хорошо. Он в любом случае не обременен какой-либо лицензией на свой код, но находится он далеко за океаном и это не я.
> Вирусность заключается в использовании gpl библиотеки с не gpl приложением.
И наоборот. GPL в этом отношении симметрична. А у меня по условиям GPL есть обязанность и зависимости GPL совместимые использовать. А я не могу так делать, так как они проприетарные.
> Если человек получил такую программу, то у него уже есть эта библиотека в том или ином виде.
Конечно же нету! Человек получил эту программу в виде набора исходников, скаченных с SF много лет назад. Понятно, что в этом наборе исходников коммерческой библиотеки нет.
> Почему он не может пересобрать GPL код и слинковаться с тем же экземпляром библиотеки?
Ровно потому, что распространять это даже в исходниках не нарушив GPL будет невозможно. Более того, у меня есть подозрение, что и использование может GPL нарушать.
> Можно библиотеку подгружать в рантайме и тогда всё будет чисто.
Это ни на что не повлияет, так как библиотека является необъемлемым компонентом. Без нее не будет работать основная логика.
Конечно же нету! Человек получил эту программу в виде набора исходников, скаченных с SF много лет назад. Понятно, что в этом наборе исходников коммерческой библиотеки нет.
И как смена GPL на что-то другое поможет в описанной вами ситуации:
А будь приложение под LGPL или MIT/BSD/Apache, то таких проблем бы не было, но GPL банально известнее и для человека, который в лицензиях разбираться не хочет куда проще поставить шильдик GPL.
GPL не позволяет линковаться с зависимостями, которые распространяются под не совместимыми с GPL лицензиями.
Всегда не позволяет. Без исключений. Для libstdc++ отдельное runtime exception пришлось добавлять к лицензии, чтобы ее можно было с закрытым кодом линьковать не смотря на GPL.
Если Вы знаете о существовании исключений, позволяющих линьковать GPL и закрытый код, то прямо укажите пункт GPL, который позволит линьковать GPL код и закрытый код.
LGPL или MIT/BSD/Apache позволяют линьковать открытый и закрытый код. Вот чем они помогут в данной ситуации. Я смогу легально скачать LGPL код зависящий от закрытого кода, использовать его, доработать его и, что самое главное, открыть миру свои изменения под LGPL не нарушив ее! И при этом у меня не будет обязанности открыть под GPL зависимости — те этот краеугольный закрытый код, которого у меня даже и нету, только готовая библиотека.
И еще, скачайте, пожалуйста, демо версию коммерческой поставки Qt и opensource версию Qt и посмотрите на драйвера к базам данных в модуле QtSQL. Вы обнаружите, что OpenSource Qt не содержит драйверов к закрытым базам данных, а если вы посмотрите в документацию к Qt, то там написано, что часть драйверов отсутствуют в открытой Qt из-за несовместимости проприетарного кода и GPL. Те ситуация один в один, как я и описываю.
И да, минусы ставить куда проще, чем привести пункт GPL, который разрешает линьковать закрытый и GPL код, что сразу бы прекратило спор, но я такого пункта там не видел…
А закрытый код — это данность, от которой не уйти. Intel MKL, Intel IPP, тот же IMSL с которым правда работать не доводилось — это закрытый код, у которого и близких OpenSource конкурентов по производительности нету.
GPL не позволяет линковаться с зависимостями, которые распространяются под не совместимыми с GPL лицензиями.
Всегда не позволяет. Без исключений. Для libstdc++ отдельное runtime exception пришлось добавлять к лицензии, чтобы ее можно было с закрытым кодом линьковать не смотря на GPL.
GPL запрещает делать закрытое приложение с открытыми библиотеками. Об обратном GPL ничего не говорит.
Те ситуация один в один, как я и описываю.
Это другая ситуация. Qt это библиотека. Она не может распространять библиотеки связанные с MS SQL или Oracle. Однако при наличие необходимых библиотек, вы можете собрать драйвер.
Я смогу легально скачать LGPL код зависящий от закрытого кода, использовать его, доработать его и, что самое главное, открыть миру свои изменения под LGPL не нарушив ее! И при этом у меня не будет обязанности открыть под GPL зависимости — те этот краеугольный закрытый код, которого у меня даже и нету, только готовая библиотека.
А будь приложение под LGPL или MIT/BSD/Apache, то таких проблем бы не было, но GPL банально известнее и для человека, который в лицензиях разбираться не хочет куда проще поставить шильдик GPL.
Так у вас есть библиотека или нет? Можно сделать как в Qt и работу с библиотекой сделать через плагин. Вы не линкуетесь с библиотекой и с GPL все чисто.
GPL не разделяет приложение и библиотеки, а оперирует понятием «Corresponding Source»: The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. (обратите внимание на «run the object code»).
Особенно обратите внимание на часть: For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
А дальше пошли обязанности:
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
Как я смогу распространять Corresponding Source дальше на условиях GPL, если в него входит «dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work», а эта самая dynamically linked subprograms имеет закрытый код?
> Так у вас есть библиотека или нет?
Да.
> Можно сделать как в Qt и работу с библиотекой сделать через плагин.
С библиотекой, которая всю математику ядра приложения считает? Ну ну…
Но даже плагин меня не спасет от запрета на распространение измененного кода…
Очень просто, приходит к вам заказчик и говорит — вот есть GNOME, меня в нём многое устраивает, но надо изменить это, это и это, плачу миллион долларов. Ах да, код изменений должен быть только у меня. Вы могли бы здорово заработать, да и человеку, может быть, помочь — а хрен там, GPL говорит вам валить лесом.
Мне как разработчику вообще шикарно. Работу выполнил, все права на свой код передал заказчику. Дальше забота заказчика, что он будет с этим кодом делать.
не можете просто «передать его заказчику»
В РФ я могу это сделать через договор об отчуждении исключительного права. Я отказываюсь от своих авторских прав в пользу заказчика.Собственно в РФ по трудовому законодательству так все и происходит. Любой мой код, является собственностью работодателя.
форму трудовых отношений с работодателем вы должны выбирать
Где это написано?
Передавать права на написанное не получится, поскольку вы этими правами в случае модификации кода на GPL не обладаете.
Я обладаю авторским правом на изменения. Это право я могу передать.
Где это написано?
В Вашем комментарии выше.
Я обладаю авторским правом на изменения. Это право я могу передать.
Так а толку? Для получения конечного продукта заказчику придётся взять не только Ваши изменения, но и оригинал кода (который под GPL). И получить всю прелесть невозможности его использования для большинства классических коммерческих кейсов.
И получить всю прелесть невозможности его использования для большинства классических коммерческих кейсов.
Меня как исполнителя это не беспокоит. Мне поставили задачу модифицировать GNOME, я его модифицировал. Что дальше будет делать заказчик с этой версией меня не волнует.
Вы категорически ошибаетесь. GPL обязывает только передавать код вместе с продуктом. Я могу передать измененный GPL код одному заказчику. (Другое дело, что я не могу запретить заказчику передавать код дальше, но заказчик во многих случаях и сам в этом не заинтересован).
Вы должны либо открыть его всем, либо не передавать никому.Где такое написано. Вроде же GPL говорит, что код нужно передавать тому, кому передается программа, а не всем!
На Линуксе давно надо навести порядок в области создания десктопных юзерских программ.
Это невозможно. Это opensource в действие. Здесь если кому-то, что-то не нравится, то пишут своё. Поэтому и имеет вагон gui библиотек для C++, куча DE, а всяких плееров и не счесть.
А вот стартапы в полном пролёте.
Странные стартапы. Т.к. фонд заработной платы с участием middle и senior разработчиков намного больше 500$. Может быть вы имели ввиду фрилансеров?
В результате мелкий коммерческий софт под Линукс написан кто во что горазд
Пишут на том, что лучше всего знают.
>> Python для Линукса — де факто главный язык пользовательского софта.
Вот это вы откуда взяли?
>> Но вот эта конструкция с moc и генерируемым кодом создаёт сложности при попытке привязать Qt к другому языку.
Вообще не оттуда сложности берутся…
>> Ты можешь хотеть выложить свой код под MIT или вообще PD, но облом… в одну программу нельзя юридически включать PyQT и коммерческую библиотеку… ты хочешь потрудиться на благо сообщества, а вместо этого юлишь между законами
Собственно, если хочешь потрудиться на благо сообщества — чем GPL не устраивает? Она для того и придумывалась, чтобы трудиться на благо сообщества.
Тем более, что юлить между законами, как правило, наказуемо, «способы извернуться» — заведомо неверный путь, а «в основном всем просто пофиг» — откровенно ошибочное мнение.
>> кто во что горазд: С++/Qt, Python/Gtk, Go/wxWidgets, NodeJS/(какой фреймворк? ручками нарисую!)
Собственно «C++/Qt» — дефолтное поведение, для того и разрабатывалось, «Python/Gtk» — а почему не Java/Gtk? не C/Gtk? Не С++/Gtk?
>> «а умеет ли Линукс HiDPI? Экраны Брайля? Скины? Чтение с экрана?»
Какбэ, вот эта унификация изначально в другой плоскости. Ждите Wayland-во-все-поля, остальное подтянется.
>> А в глобальных размышлениях о судьбах Линукса они не участвуют.
Какбэ, и слава Б-гу. И вы завязывайте!)
>> хотя Линукс и переходит понемногу на Qt
Вот это вы откуда взяли? Торвальдс в курсе?
Развенчание мифов о мета-объектном компиляторе Qt