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

[Авварон]

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

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

Я не знаю, примитивная ли ваша функция или нет, я не смотрел. Если вам её надо - отправьте патч кутешникам. Если это разумное действие, патч примут и в следующей версии ваша функция будет в паблик API:)

[AzazelloAV]

Я не знаю, примитивная ли ваша функция или нет, я не смотрел. Если вам её надо - отправьте патч кутешникам. Если это разумное действие, патч примут и в следующей версии ваша функция будет в паблик API:)

Не примут. Патч должен был отправить тот разработчик из команды Qt, который скопировал эту функцию. Совещался ли он с коллегами про такую "ерунду". Однозначно. Но решили по другому. Тем более синхронизировали документацию с разработчиком другого модуля.

[Igors]

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

В основном - параметры (на каком регистре что), само по себе имя неинтересно. Кстати вот типичная рекомендация

Заруби себе на носу. Все модули программы (разделяемые библиотеки, статические библиотеки) на C++ должны быть собраны одним компилятором, с одинаковыми опциями компиляции. Иначе - беда.

Это, строго говоря, неверно. Требуется совместимость ABI. И сишные либы ходят без перекомпиляции т.к. эту совместимость имеют. И мудизм debug/release (версии либы) только на Вындоуз.

Все же непонятно каким боком это касается Вас лично. Др словами ну зачем следовать правилам бинарной совместимости в обычном, рабочем коде? Ладно, это Ваше личное дело, в любом случае спасибо за подробные объяснения.

[Авварон]

Все же непонятно каким боком это касается Вас лично. Др словами ну зачем следовать правилам бинарной совместимости в обычном, рабочем коде? Ладно, это Ваше личное дело, в любом случае спасибо за подробные объяснения.

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

[Igors]

- если вы клепаете формочки (а вы, очевидно, клепаете),