Поправьте меня, то как раз «эмоции, жесты, интонации голоса» сейчас просто захватывают с реальных актеров, так что это ИХ харизма. Не создавать, а пока просто копировать, не более чем «я слышал где-то музыкальный шедевр, вот, записал ноты» — но это не делает меня творцом.
Один контрпример:
— ядро linux написано на C и там нет неймспейсов;
— в С++ они есть, поэтому запас по сложности у него выше;
Ну-ка, покажите хоть одно ядро ОС на С++ сравнимой сложности с Linux? А? Где оно?
P.S>
( я прекрасно знаю области применения обоих языков, это шутка!)
«Кроме того, необходимость предоставлять объектные файлы — не очень.»
а что конкретно не очень?
в них содержится столько же информации, сколько и в dylib/so, ну если не оставлять дебажные символы, конечно. Я не прав?
Неудобно для пользователя — возможно, но мы же о соблюдении лицензии и ее свобод говорим.
Это распространенное заблуждение, про то что GPL/LGPL речь только о dll-ках.
Ты можешь Qt поставлять и в виде dll-ки, но если в приложении будешь проверять его чексумму, например, LGPL будет нарушен, т.к. пользователь не сможет сам заменить библиотеку.
Mingw64 это форк Mingw, в нем нет ничего неофициального. Запиливание полноценной работы с 64-битной виндой изначально было одним из приоритетов проекта.
Меня немного удивило то что 32-битных сборок mingw теперь нет)
Не обновление как таковое, а отсутствие стабильного API. Это как в Linux kernel. По сути, мотивация пропихнуть свой плагин в апстрим примерно такая же — чтобы снять головную боль при изменении API.
Более того, не знаю как у вас, я сталкивался с тем что в минорном апдейте все отваливалось даже.
Ну хорошо, по крайней мере из вашего коммента я понял, что сфера применения у них примерно одна и та же, спасибо.
Генерация XML протокола — ну да, пожалуй, этого отличия достаточно.
«Ну D-Bus это только Linux, потому на Mac OS и Windows он не работает»
чегоооооо
О_О
А я его использовал в промышленной системе на Windows, причем таки в его обертке QtDbus как раз, а оказывается он там не работает…
(картинка со столом и водкой)
(а, ну я вроде сам libdbus собирал, не помню, шел ли модуль в стандартном инсталляторе, правда, но факт -это все заводится вполне).
Вы ничего не перепутали?
Да, под win сейчас там отключена работа через pipe-ы (там вроде туду было в коде), но через сетевые сокеты все норм работает, и судя по замерам производетельности, это не такая уж большая потеря (большой объем данный по dbus все равно не гоняется)
«то есть вы работаете не с чем-то там, а со знакомыми сигналами и слотами.»
вот именно dbus в qt — работаешь с сигналами и слотами. Совершенно естественным кутешным образом. Что не так?
Можете больше рассказать о Qt Remote Objects, как они позиционируются вообще? Я посмотрел документацию, примеры, но так и не понял, какое прикладное решение можно с ними нагородить.
Для обеспечения «банального» IPC куда лучше QtDbus сейчас справляется (он кросплатформенный и так же может работать и по сети).
Примеры какие-то уж больно синтетические в документации.
Боюсь, дело не в суровости наказания. Что толку от «отрубания рук» если, как уже упомянул автор, все заканчивается «давайте не будем выносить сор из избы»? Руки-то может и отрубят. Но совсем не тем.
Еще вопрос от С++ разработчика — есть какие-то планы по работе над скоростью С++ компилятора? а то замедление в 3.5 раза просто при смене 2015-> 2017 вообще не радует.
Поправьте меня, то как раз «эмоции, жесты, интонации голоса» сейчас просто захватывают с реальных актеров, так что это ИХ харизма. Не создавать, а пока просто копировать, не более чем «я слышал где-то музыкальный шедевр, вот, записал ноты» — но это не делает меня творцом.
— ядро linux написано на C и там нет неймспейсов;
— в С++ они есть, поэтому запас по сложности у него выше;
Ну-ка, покажите хоть одно ядро ОС на С++ сравнимой сложности с Linux? А? Где оно?
Видели такое? Я не спец, но что-то такое) сам eigen не использовал.
eigen.tuxfamily.org/index.php?title=Licensing_FAQ&oldid=1117#What_is_the_LGPL.3F
а что конкретно не очень?
в них содержится столько же информации, сколько и в dylib/so, ну если не оставлять дебажные символы, конечно. Я не прав?
Неудобно для пользователя — возможно, но мы же о соблюдении лицензии и ее свобод говорим.
C++->Code Model-> Manage…
Ты можешь Qt поставлять и в виде dll-ки, но если в приложении будешь проверять его чексумму, например, LGPL будет нарушен, т.к. пользователь не сможет сам заменить библиотеку.
Меня немного удивило то что 32-битных сборок mingw теперь нет)
Более того, не знаю как у вас, я сталкивался с тем что в минорном апдейте все отваливалось даже.
Генерация XML протокола — ну да, пожалуй, этого отличия достаточно.
чегоооооо
О_О
А я его использовал в промышленной системе на Windows, причем таки в его обертке QtDbus как раз, а оказывается он там не работает…
(картинка со столом и водкой)
(а, ну я вроде сам libdbus собирал, не помню, шел ли модуль в стандартном инсталляторе, правда, но факт -это все заводится вполне).
Вы ничего не перепутали?
Да, под win сейчас там отключена работа через pipe-ы (там вроде туду было в коде), но через сетевые сокеты все норм работает, и судя по замерам производетельности, это не такая уж большая потеря (большой объем данный по dbus все равно не гоняется)
«то есть вы работаете не с чем-то там, а со знакомыми сигналами и слотами.»
вот именно dbus в qt — работаешь с сигналами и слотами. Совершенно естественным кутешным образом. Что не так?
Для обеспечения «банального» IPC куда лучше QtDbus сейчас справляется (он кросплатформенный и так же может работать и по сети).
Примеры какие-то уж больно синтетические в документации.
Видимо, к этому.