"Закрытость" Qt

[Авварон]

Как это не будет. Очень даже будет. Если брать мой пример, с подсвечиванием элемента, где рисуется рамочка изменение поведения этого подсвечивания в самой Qt приведёт к тому, что опять мне эту рамочку нужно будет копипастить. Да и вообще, её же для меня нету (этой функции), её воообще могут убрать и придумать совершенно другое.

Не будет. Публичное API останется таким же. Еще раз - рамки станут рисоваться ПО РАЗНОМУ, но код продолжит работать и будет делать то, что делал раньше (старый вариант).

[Igors]

C API имеет те же проблемы - нельзя менять структуры и удалять ф-ии. Менять сигнатуру нельзя. С оверлоадами вообще ад.

Должен быть известен размер структуры, передается в параметрах или записан в самой структуре. Callback(и) (плагин зовет хост) имеют ID команды. Оба (плагин и хост) возвращают код ошибки. Вот собственно и все. Расширять - без проблем. Остальное (менять поля и.т.п) - ну так это недостижимо, не стоит к этому стремиться.

Вместо этого накручивается какой-то свод правил, которому почему-то надо следовать. Хорошо еще не вспомнили про "возврат интерфейса" - эта манечка загубила немало молодых ребят.

С плагинами никаких проблем нет - можно сделать либо новый интерфейс, к-ый поддерживается тем же манагером, либо унаследовать новый от старого (если старое АПИ надо расширить, а не заменить).

Как-то не звучит чему же это посвящено. Не так уж поздно наступает момент когда все плагины надо перекомпилить/переписать. Портирование на 64 бит, до этого на Intel Mac, на Carbon, на PPC - всякий раз ВЕСЬ софт нужно было обновить. И всякий раз "портирование" совсем не было "просто перекомпилить". В общем это неизбежно, "бинарная совместимость" не спасает. А раз так то и нечего ее раздувать 

[Авварон]

С плагинами никаких проблем нет - можно сделать либо новый интерфейс, к-ый поддерживается тем же манагером, либо унаследовать новый от старого (если старое АПИ надо расширить, а не заменить).

Как-то не звучит чему же это посвящено. Не так уж поздно наступает момент когда все плагины надо перекомпилить/переписать. Портирование на 64 бит, до этого на Intel Mac, на Carbon, на PPC - всякий раз ВЕСЬ софт нужно было обновить. И всякий раз "портирование" совсем не было "просто перекомпилить". В общем это неизбежно, "бинарная совместимость" не спасает. А раз так то и нечего ее раздувать 

Без бинарной совместимости ЛЮБОЕ обновление ОС (читай - линукса с кедами) ломало бы весь софт. Никто (кроме гентушников) не будет пересобирать полоперационки при каждом обновлении Qt. Почему вы пыаетесь применять практики, возможные в приложении на библиотечный код? Я кстати давно заметил, что почти никто не умеет писать библиотеки общего пользования.

[Igors]

Без бинарной совместимости ЛЮБОЕ обновление ОС (читай - линукса с кедами) ломало бы весь софт. Никто (кроме гентушников) не будет пересобирать полоперационки при каждом обновлении Qt. Почему вы пыаетесь применять практики, возможные в приложении на библиотечный код? Я кстати давно заметил, что почти никто не умеет писать библиотеки общего пользования.

Про линукс с кедами ничего не знаю, но на Mac именно так и было - да, ломался ВЕСЬ софт. Пару лет давали попастись на "эмуляторе" (нар Розетта), а потом "с приветом".

Ну и зачем мне это уметь? И что есть "библиотека общего пользования"? Вот хотя бы либа FBX, общего ли она пользования? По-народному да, многие приложения ее пользуют. И бинарная совместимость там очень простая - все идет в namespace имя которого = номер версии. Вот файлы да, и сверху вниз и наоборот. А это - зачем? Нужны новые фичи/подформаты, ну так обновляйтесь. Совместимось приложение-плагины решается куда более простыми средствами. Поэтому да, мне это кажется преувеличенным и раздутым, не знаю ни одного примера где это актуально.   

[Авварон]

Про линукс с кедами ничего не знаю, но на Mac именно так и было - да, ломался ВЕСЬ софт. Пару лет давали попастись на "эмуляторе" (нар Розетта), а потом "с приветом".

Это не любое обновление. Qt тоже ломает совместимость раз в Н лет между мажорными релизами. А теперь представьте, что вам ВЕСЬ софт надо пересобирать\переставлять КАЖДУЮ НЕДЕЛЮ

[AzazelloAV]

Это не любое обновление. Qt тоже ломает совместимость раз в Н лет между мажорными релизами. А теперь представьте, что вам ВЕСЬ софт надо пересобирать\переставлять КАЖДУЮ НЕДЕЛЮ

Что самое интересное, так и происходит.

Но вы так и не рассказали, как сосущесвует этот мир. Возьмём Windows, в виду её закрытости легче рассуждать. Как дружат с бинарниками почти с десяток компилятров. Опять же, если вы обладаете знаниями в этой теме, прошу поделиться. У меня их к примеру нету. Отбросим COM интерфейсы, с ними всё понятно.

Хотя, сдаётся мне, просто там не присутствуют плюсы в виде доступного айпи.

[Авварон]

Что самое интересное, так и происходит.

Но вы так и не рассказали, как сосущесвует этот мир. Возьмём Windows, в виду её закрытости легче рассуждать. Как дружат с бинарниками почти с десяток компилятров. Опять же, если вы обладаете знаниями в этой теме, прошу поделиться. У меня их к примеру нету. Отбросим COM интерфейсы, с ними всё понятно.

Я не знаю, что у вас там происходит, когда мне приходит  обновление Qt на линуксе, у меня не обновляются кеды, к-ые от них зависят. Когда приходит обновление фреймворков на маке, не обновляются программы, которые от них зависят.

Давайте возьмем виндовз - программы, собранные в ХР отлично работают в 7ке. Если бы не было бинарной совместимости kernel32.dll хрен бы вы что запустили.

[AzazelloAV]

Я не знаю, что у вас там происходит, когда мне приходит  обновление Qt на линуксе, у меня не обновляются кеды, к-ые от них зависят. Когда приходит обновление фреймворков на маке, не обновляются программы, которые от них зависят.

Давайте возьмем виндовз - программы, собранные в ХР отлично работают в 7ке. Если бы не было бинарной совместимости kernel32.dll хрен бы вы что запустили.

Ну вы уж так сразу категорично. Qt же мы сами исключили из данного опуса, т.к. у них с бинарной совместимостью всё ок.
Я же специально на windows переключился, а там постоянно что либо да обновляется.
Тогда вопрос более конкретный, раз затронули kernel32. Вы хотите сказать что он со времён Windows 3.1 не менялся?

[Авварон]

Тогда вопрос более конкретный, раз затронули kernel32. Вы хотите сказать что он со времён Windows 3.1 не менялся?

Конечно менялся. Но за всё это время бинарная совместимость не была нарушена.

[AzazelloAV]

Конечно менялся. Но за всё это время бинарная совместимость не была нарушена.

Вообще кернел неудачный пример. О какой бинарной совместимости можно говорить, если функции вызываются по имени, ну в далёком прошлом по номеру. Там по барабану, там же нет интерфейса плюсов.

Ладно, тупик.
Но как уживаются разные компиляторы на одной системе. Так уж у них стандартазирована vmt?. Если так, то почему на линухе смена компилятора не тривиальная задача.

[Авварон]

Вообще кернел неудачный пример. О какой бинарной совместимости можно говорить, если функции вызываются по имени, ну в далёком прошлом по номеру. Там по барабану, там же нет интерфейса плюсов.

Ладно, тупик.
Но как уживаются разные компиляторы на одной системе. Так уж у них стандартазирована vmt?. Если так, то почему на линухе смена компилятора не тривиальная задача.

Не знаю, никогда не вызывал ф-ии винапи по имени:)

На линухе компиляторы отлично уживаются - шланг с гцц можно мешать как душе угодно. Причем не очень понимаю, почему вы разговор о совместимости версий библиотек переводите разговор на совместимость ABI. Разве что, вы не понимаете что есть что:)

[AzazelloAV]

Не знаю, никогда не вызывал ф-ии винапи по имени:)

Это потому что за вас "привязку" сделали - описали прототипы, уже молчу даже про паскалевский тип вызова.

Ааааа. Вы не поняли, что я имел в виду. По имени в виде строки.

На линухе компиляторы отлично уживаются - шланг с гцц можно мешать как душе угодно. Причем не очень понимаю, почему вы разговор о совместимости версий библиотек переводите разговор на совместимость ABI. Разве что, вы не понимаете что есть что:)

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

Во первых, действительно не понимаю, как разные компиляторы уживаются друг с другом (что вы назвали ABI).
Во вторых, не понял, что вы имеете в виду под "шланг с gcc".
И в третих нить треда потерялась, скоро спутники начнём запускать.

Но для себя я определённые выводы сделал.

С чего начиналось - есть функция, которая копируется внутри самих исходников Qt. На вопрос почему вы уже ответили: "Не время её сейчас выпячивать, чтобы ничего не ломать" либо "А ну его, так проще, чтобы ничего не ломать."

[AzazelloAV]

Не знаю, никогда не вызывал ф-ии винапи по имени:)

Это потому что за вас "привязку" сделали - описали прототипы, уже молчу даже про паскалевский тип вызова.

О.... Вы не поняли, что я имел в виду. По имени в виде строки.

На линухе компиляторы отлично уживаются - шланг с гцц можно мешать как душе угодно. Причем не очень понимаю, почему вы разговор о совместимости версий библиотек переводите разговор на совместимость ABI. Разве что, вы не понимаете что есть что:)

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

Во первых, действительно не понимаю, как разные компиляторы уживаются друг с другом (что вы назвали ABI).
Во вторых, не понял, что вы имеете в виду под "шланг с gcc".
И в третих нить треда потерялась, скоро спутники начнём запускать.

Но для себя я определённые выводы сделал.

С чего начиналось - есть функция, которая копируется внутри самих исходников Qt. На вопрос почему вы уже ответили: "Не время её сейчас выпячивать, чтобы ничего не ломать" либо "А ну его, так проще, чтобы ничего не ломать."

[Авварон]

Это потому что за вас "привязку" сделали - описали прототипы, уже молчу даже про паскалевский тип вызова.

Кто сделал привязку? О чем вы вообще? Это просто 2 разных способа работы с библиотекой - динамическая загрузка или линковка. В обоих способах либа предоставляет набор экспортируемых функций, как их вызывать - ваше дело.

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

Во первых, действительно не понимаю, как разные компиляторы уживаются друг с другом (что вы назвали ABI).
Во вторых, не понял, что вы имеете в виду под "шланг с gcc".

0) Вместо кернела возьмите любую системную библиотеку:) Для вашего удобства я взял известную вам либу, а не CoreFoundation.framework какой-нибудь:)
1) шланг = clang, яблочный компилятор.
2) Начну издалека.
Есть формат бинарника - это то, как располагаются секции кода\данных в исполняемом файле, формат заголовков и тому подобное. Как правило, на каждой операционке свой формат - в винде .exe, в линупсе ELF, на маке - mach-o.

Есть архитектура бинарника - один и тот же формат подерживает разные архитектуры (какая разница, какие чиселки лежат в секции кода)

Есть ABI - это высокоуровневое понятие, связанное с тем, как именовать экспортируемые ф-ии в библиотеке и как передавать параметры. Для си ABI относительно стандартизовано - имя экспортируемой ф-ии не меняется, передача параметров регулируется пачкой макросов (вы можете указать компилятору как звать ту или иную библиотечную функцию). Поэтому extern "C" функции отлично понимают любые компиляторы.
Для с++ ABI не стандартизовано. Например, нет стандарта на именование экспортируемой ф-ии (как правило, это XXXNamespaceXXXClassXXXParam1XXX где ХХХ - это какой-то непонятный набор символов, у всех компиляторов разный). Или то, где размещать vtable (обычно, она лежит первым членом класса, но вот борланд размещает ее ПЕРЕД классом). Соответственно, есть понятие "ABI компилятора X" - это ABI, к-ый является "родным" для компилера X. В линуксе/маке основным является ABI gcc, поэтому, для совместимости, clang также использует это ABI (и полностью совместим с gcc). На венде основным является ABI msvc, но у него есть проблема - это ABI разный для разный версий комилятора. По этой причине (а на самом деле просто не осилили) остальные компиляторы юзают своё ABI, не совместимое с msvc (речь про плюсы, как я говорил, си стандартизовано) - у mingw gcc'шное ABI. Аналогично clang под вендой - по умолчанию использует ABI gcc; вместе с тем, работы по эмуляции ABI msvc также ведутся, но не очень успешно.

И, наконец, есть понятие Binary Compatibility - это совместимость разных версий одной и той же библиотеки. Если вы можете подменить либу Х версии А на версию А+1 и приложение запустится, это значит, что версия А+1 бинарно совместима с версией А.

С чего начиналось - есть функция, которая копируется внутри самих исходников Qt. На вопрос почему вы уже ответили: "Не время её сейчас выпячивать, чтобы ничего не ломать" либо "А ну его, так проще, чтобы ничего не ломать."

Нет, я ответил наоборот - "мы ее сейчас выпятим, а потом окажется, что эта функция не нужна, а удалить ее не сможем". Чтобы что-то выпятить наружу надо понять а) нужно ли это достаточному числу пользователей б) если нужно, то нужно ли это в том виде, в каком оно сейчас в) что будет с этой функцией через 5 лет. Это всё ненулевая работа, которую надо делать. Если у вас есть лишнее время - вперед, займитесь. В Qt действительно много кода, который не помешало бы выпятить. Ради бога, начните только с platform extras:)

[AzazelloAV]

Нет, я ответил наоборот - "мы ее сейчас выпятим, а потом окажется, что эта функция не нужна, а удалить ее не сможем". Чтобы что-то выпятить наружу надо понять а) нужно ли это достаточному числу пользователей б) если нужно, то нужно ли это в том виде, в каком оно сейчас в) что будет с этой функцией через 5 лет. Это всё ненулевая работа, которую надо делать. Если у вас есть лишнее время - вперед, займитесь. В Qt действительно много кода, который не помешало бы выпятить. Ради бога, начните только с platform extras:)

Спасибо за ответ, проанализирую (тот, который вырезал) чуть позже, хотел ответить.
Вы совершенно верно сказали одну вещь, в которую мало кто врубается из за сложности понимания её - мол мало люда умеет писать библиотеки общего назначения. Да это ****ец как сложно! Ведь вы согласны, что такая либа должна учитывать "пожелания" пользователей, ожидаемое поведение на много лет вперёд и т.д и т.п. (молчу про качество самой библиотеки, тестирование её и все такое). В прямом смысле слова, разработчики таких библиотек должны обладать определённым даром (пусть высокопарно). Конечно, можно начинать с кандачка, но это больше касается узкоспециализированных бибилиотек и в конце концов там ужас.......

А с чем же с вами не согласен? Сложна ли Qt в плане разработки? Офигительно! Мы понимамаем, что разработчики не хотят делать резких шагов.  Я могу привести функции которые они заложили и не реализовали (но смотрели вперёд же). Зря вам кажется, что это примитивная вещь (в плане моей функции). Нет, отбросте "одинаковое поведение", тут это не сработает. Могли они на этапе проектирования класса предвидеть это? Могли. Но это очень сложно, запросто могли пропустить.

Тем более,  что работы по "выпячиванию" данной функции внаружу вы оценили уж слишком "затратной" (в плане программирования)