На днях в Праге комитет по стандартизации С++ провел ряд опросов по вопросу изменения ABI, и в конечном счете было решено ничего в нем не менять. Аплодисментов в зале слышно не было.
Я думаю, мы не осознавали полностью те последствия, которое повлечет за собой данное решение, и я не верю, что оно в принципе может положительно сказаться на развитии языка.
...
Почему мы должны сломать ABI
Прежде всего, есть несколько полезных изменений в реализации стандартной библиотеки, которые можно внедрить, если нарушить текущий ABI:
— Сделать ассоциативные контейнеры (намного) быстрее
— Ускорить работу std::regex (На данный момент быстрее запустить PHP и выполнить на нем поиск по регулярному выражению, чем использовать стандартный std::regex)
— Некоторые изменения в std::string, std::vector, а также в разметке других контейнеров
— Единство интерфейса классов: на данный момент некоторые их реализации намеренно не соответствуют единому интерфейсу в угоду стабильности ABI
...
В какой версии C++ ждать изменений
Очевидный недостаток всех этих опросов заключается в том, что мы так и не определились, когда именно мы хотим сломать ABI.
в C++23? Нет, уже точно нет.
в C++26? Часть людей намерены голосовать за, но другая часть скорее всего проголосует за C++41 или за то время, когда они уйдут на пенсию и им не придется поддерживать свой текущий проект. Один из вопросов просто упоминал C++-какой-то; очень удобно!
Я глубоко убежден, что решение не ломать ABI в 23-м году — это самая большая ошибка, которую когда-либо делал комитет. И я знаю, что некоторые люди верят в обратное.
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, Мёртвый Даун, Вы писали:
МД>Интересная статейка, мне показалось есть что обсудить.
Мне интересно, а ABI в С++ когда-нибудь был?
И почему я про него не слышал?
Мне всегда казалось, что ABI в С++ всегда был implementation specific.
И как можно сломать, то чего нет?
Для чего я тогда реализовывал проект beautiful capi — https://github.com/PetrPPetrov/beautiful-capi ?
Для чего Microsoft придумывала технологию COM? Для чего нужен IFX COM? И куча других аналогов кросплатформенных COM?
Если ABI есть в С++, то программу можно скомпилировать при помощи Visual C++, и она будет использовать С\С++ Runttime libraries- DLL-ки msvcr__.dll и
прочие (именование зависит от версии студии), то ей можно поднусуть glibc.dll из MinGW просто переименовав DLL-ку? И она будет работать?
Или другой версии студии?
В общем часть людей хочет сделать новую STL, по сути Boost или даже более толстый фреймворк. Но фишка STL в том, что она как правило распространяется вместе с компилятором языка.
1) Готовы ли производители компиляторов выпускать все хотелки ждунов?
2) А ничего, что тот, кого будет не устраивать новая STL автоматически останется на предыдущих версиях языка C++?
3) Ещё не нужно забывать, что некоторые разработчики компиляторов забивают на стандарт, а другие тщательно его соблюдают и поддерживают все предыдущие версии. Чем больше выдумают, тем больше у первых причин будет забивать на стандарт ещё больше, а у вторых работы по поддержанию всех версий.
4) Заблуждение, что создав свою супермега версию стандартной библиотеки, все разработчики тут же отринут свои велосипеды и перейдут на неё. STL как это ни странно всё равно чужеродна другим разработчикам начиная с имён и кончая реализацией.
В общем пусть делают, если хотят. Лично я уверен, что за глаза хватило бы и ISO/IEC 14882:2003, а то и вовсе ISO/IEC 14882:1998. А то чего не хватает, добирать сторонними библиотеками. Но мне новые стандарты и сейчас нисколько не мешают, поскольку я их не использую. У C++ не такая политика, чтобы поломать все предыдущие стандарты и поддерживать только самое новое, потому можно на всё это забить.
МД>На днях в Праге комитет по стандартизации С++ провел ряд опросов по вопросу изменения ABI, и в конечном счете было решено ничего в нем не менять.
Я всегда говорил, что динамические библиотеки — это зло в чистом виде, но вот о том, что они могут препятствовать развитию C++ не думал. Практика показывает, что если есть две версии бесплатной программы: со статической линковкой и с динамическими модулями, то статическая версия всегда выигрывает по количеству инсталлированных копий. Я вообще не вижу причин использовать бинарные модули, кроме лицензионных.
Однако, в комментариях там замечают, что автор не прав в том смысле, что он предполагает (неявно) поломку API, а не ABI. Вот API нельзя ломать категорически.
Так же в комментариях верно подмечено, что Qt ломает своё ABI каждый мажорный релиз — и всё хорошо.
Здравствуйте, Мёртвый Даун, Вы писали:
МД>Интересная статейка, мне показалось есть что обсудить.
А чего тут обсуждать, я пока ниразу не встречал использование бинарников в том виде каком они есть, всегда делается сборка библиотек с попыткой использовать одни и теже ключи компиляции, поэтому сломают ABI или не сломают, мне работы не уменьшится. Мне даже интересно, у кого в проекте используется dll, so, dylib собраный не вами а скачаный откуда-то?
Здравствуйте, Igore, Вы писали:
I>Мне даже интересно, у кого в проекте используется dll, so, dylib собраный не вами а скачаный откуда-то?
По большей части собираем из исходников. Однако есть одна такая, с закрытыми исходниками, ее используем скачанную — https://www.opendesign.com/
И еще сами свою библиотеку даем своим заказчикам в собранном виде (тоже закрытая).
Но свою обернули при помощи beautiful capi — https://github.com/PetrPPetrov/beautiful-capi
Получается такая standalone DLL, из зависимостей на Windows по большому счёту только KERNEL32.DLL,
C\C++ Runtime library влинкован статически (/MT ключик), API самой DLL — только Сишный, используются типы unit32_t, uint8_t
и только такие, исключения наружу не проскакивают.
У клиента есть выбор — использовать или C-API, либо использовать С++ врапперы (набор header only классов; реализованных при помощи С++ 98),
которые реализованы поверх вызовов нашего C-API.
Внутри наша библиотека использует С++ 14 (построенна при помощи Visual Studio 2019),
а вот клиент может ее использовать хоть в Visual C++ 6.0 (C++ 98), и какой-то другой компилятор (Clang для Windows, GCC из MinGW и т.д.).
Причем клиент может использовать любые ключи компиляции для своего приложения —
нет никакой необходимости в соответствии ключей компиляции его приложения и нашей библиотеки.
МД>>На днях в Праге комитет по стандартизации С++ провел ряд опросов по вопросу изменения ABI, и в конечном счете было решено ничего в нем не менять.
BFE>Я всегда говорил, что динамические библиотеки — это зло в чистом виде, но вот о том, что они могут препятствовать развитию C++ не думал.
Динамические библиотеки не препятствуют развитию C++.
Если библиотека подложки меняется с несовместимой сменой API, то перекомпилировать под неё нужно одинаково и в случае статических, и в случае динамических библиотек.
BFE> Практика показывает, что если есть две версии бесплатной программы: со статической линковкой и с динамическими модулями, то статическая версия всегда выигрывает по количеству инсталлированных копий. Я вообще не вижу причин использовать бинарные модули, кроме лицензионных.
Какой-то странный переход к бинарным модулям от динамических библиотек.
Практически единственный недостаток динамических библиотек — это что с ними код чуть медленнее, из-за подключения подгружаемых функций через санки. И то можно делать без них.
Ну и ещё с ними тотальный LTO не получается.
Остальное — в плюс.
BFE>Однако, в комментариях там замечают, что автор не прав в том смысле, что он предполагает (неявно) поломку API, а не ABI. Вот API нельзя ломать категорически.
Да, непонятно, почему вообще речь про ABI, если фактор типа возвращаемого значения метода это API.
Им придётся расширять стандартную библиотеку и ломать как ABI так и API. Иначе интерес к языку уйдёт.
Библиотеку придётся расширять так как просто голый язык уже нафиг никому не нужен, каким бы хорошим он ни был.
API — чтобы повычищать тот идиотизм, что уже напринимали.
ABI — чтобы наконец-то привести "модули" (да-да, они ещё будут меняться) к адекватному состоянию.
Уже был такой период "стабильности", что спешно пришлось и с++11 и дальнейшие версии принимать, так как народ повалил на другие языки, которые активно развивались.
И если язык не развивать — то он превратится в очередной Cobol с рабочей силой в два с половиной деда на пол планеты.
Здравствуйте, GhostCoders, Вы писали:
GC>Здравствуйте, Мёртвый Даун, Вы писали:
МД>>Интересная статейка, мне показалось есть что обсудить.
GC>Мне интересно, а ABI в С++ когда-нибудь был?
Но всякие трюки типа pimpl, который использует Qt для STL явно не подойдут.
GC>Если ABI есть в С++, то программу можно скомпилировать при помощи Visual C++, и она будет использовать С\С++ Runttime libraries- DLL-ки msvcr__.dll и GC>прочие (именование зависит от версии студии), то ей можно поднусуть glibc.dll из MinGW просто переименовав DLL-ку? И она будет работать? GC>Или другой версии студии? GC>Да такого ни в жизнь не будет!
Но здесь я думаю конечно разговор о тех системах где используются
разделяемые, общие для все системы библиотеки с С++ ABI.
Здравствуйте, GhostCoders, Вы писали:
GC>Мне интересно, а ABI в С++ когда-нибудь был? GC>И почему я про него не слышал?
Речь, видимо, идет о том, что некоторые изменения в языке/библиотеке не оставляют даже теоретической возможности сохранить совместимость на уровне ABI. С учетом того, что практические реализации языка плевать хотели на эту совместимость, все это довольно смешно и умозрительно.
GC>Мне всегда казалось, что ABI в С++ всегда был implementation specific.
Но хоть бы внутри одной имплементации поддерживали совместимость. Хотя бы на уровне, когда можно экспортировать из динамически загружаемой библиотеки C++'ные классы (а не pure C функции), и не бояться, что перекомпиляция программы другой версией компилятора сломает ее совместимость с динамическими библиотеками.
Здравствуйте, netch80, Вы писали:
N>Практически единственный недостаток динамических библиотек — это что с ними код чуть медленнее, из-за подключения подгружаемых функций через санки. И то можно делать без них. N>Ну и ещё с ними тотальный LTO не получается. N>Остальное — в плюс.
Основной недостаток динамических библиотек — это то, что либо у тебя программа распостраняется вместе со всеми своими библиотеками, и тогда нет смысла делать их динамическими, или всегда есть риск, что какое-то сочетание версии программы с версией библиотеки будет не работать. Причем без предупреждения.
Здравствуйте, Igore, Вы писали:
I>А чего тут обсуждать, я пока ниразу не встречал использование бинарников в том виде каком они есть, всегда делается сборка библиотек с попыткой использовать одни и теже ключи компиляции, поэтому сломают ABI или не сломают, мне работы не уменьшится. Мне даже интересно, у кого в проекте используется dll, so, dylib собраный не вами а скачаный откуда-то?
А если этот so приходит со стандартным пакетом операционной системы, это считается?
Здравствуйте, Pzz, Вы писали:
Pzz>Основной недостаток динамических библиотек — это то, что либо у тебя программа распостраняется вместе со всеми своими библиотеками, и тогда нет смысла делать их динамическими
Плагины, например, могут быть только в динамических.
Для динамики можно сделать отложенную загрузку.
В динамических библиотеках можно хранить реализации, собранные для разных архитектур процессоров.
В динамических библиотеках можно прятать закрытый код.
И т.д.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, netch80, Вы писали:
Pzz>это то, что либо у тебя программа распостраняется вместе со всеми своими библиотеками, Pzz>и тогда нет смысла делать их динамическими
Ну например разделяемые библиотеки позволяют прятать символы, с помощью
`__attribute__ ((visibility ("hidden")))` или его аналога.
Это позволяет прятать статические библиотеки внутри динамической,
не показывая их наружу, то есть например иметь две разные
версии одной библиотеки с одинаковыми именами функций, если эти две разные библиотеки
являются частями разных разделяемых библиотек.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, Pzz, Вы писали:
Pzz>>Основной недостаток динамических библиотек — это то, что либо у тебя программа распостраняется вместе со всеми своими библиотеками, и тогда нет смысла делать их динамическими
N>Плагины, например, могут быть только в динамических.
И как частный случай плагинов — использование нескольких языков программирования.
Например Java/Python/php/C# вызывают C/C++ код, тогда придется собрать свой код в виде
разделяемой библиотеки.
Здравствуйте, Igore, Вы писали:
I>Здравствуйте, Мёртвый Даун, Вы писали:
МД>>Интересная статейка, мне показалось есть что обсудить.
I>А чего тут обсуждать, я пока ниразу не встречал использование бинарников в том виде каком они есть, всегда делается сборка библиотек с попыткой использовать одни и теже ключи компиляции, поэтому сломают ABI или не сломают, мне работы не уменьшится. Мне даже интересно, у кого в проекте используется dll, so, dylib собраный не вами а скачаный откуда-то?
у меня солянка из so/dll разных компиляторов, часть я даже и не слышал вообще в зависимости от платформы, но легко (пока) решается тем, что врапперы делаются над чистым С, плюсами тами и не пахнет, боли не хочется.
Здравствуйте, Pzz, Вы писали:
Pzz>А если этот so приходит со стандартным пакетом операционной системы, это считается?
Думаю, что считается. Однако, если вы собрали программу на одном дистрибутиве Linux,
то будете ли тащить этот so в другой дистрибутив Linux, или будете полагать (или требовать у пользователя установить недостающий пакет),
и данный so на новом дистрибутиве будет нужной версии и будет ABI-совместим с вашей программой?
Просто я как-то часто сталкивался со случаями, когда надо установить какую-то программу (особенно на CentOS)
и она скачиваетя в бинарной форме (нет исходников, закрытые, или даже исходники есть, но собирать влом),
и вот этот готовый бинарник программы требует более новой версии GLIBC, а его в моем дистрибутиве (был CentOS 6.x) его нет.
Я пытался собрать GLIBC — тот еще гемморой, проще дистрибутив Linux поменять.
Я к тому, что Linux и Windows — разные миры. В Linux все библиотеки используются из стандартных пакетов, в Windows — обычно все тащат с собой, свое.
Но в Linux есть проблема разных дистрибутивов (не всегда в нужном дистрибутиве данный пакет будет присутствовать в списке стандартных, часто присутствует, но все же бывает
иногда и нет), еще и GLIBC часто присутствует один для всех программ и он системный.
Такое вот чувство, что это линуксоиды С++-шники панику поднимают — у них он (ABI) присутствует, есть что терять.
Здравствуйте, Pzz, Вы писали:
N>>Практически единственный недостаток динамических библиотек — это что с ними код чуть медленнее, из-за подключения подгружаемых функций через санки. И то можно делать без них. N>>Ну и ещё с ними тотальный LTO не получается. N>>Остальное — в плюс.
Pzz>Основной недостаток динамических библиотек — это то, что либо у тебя программа распостраняется вместе со всеми своими библиотеками, и тогда нет смысла делать их динамическими, или всегда есть риск, что какое-то сочетание версии программы с версией библиотеки будет не работать.
Да, риск есть. Например, вдруг какая-то функция Windows перестанет работать. Ядро ведь для юзерленда оно, по сути, динамическая библиотека, с линковкой через сисколлы, или через библиотеки типа user32.dll.
И мы всё равно миримся с этим, потому что альтернативы нет, не тащить ведь полную ОС за своим приложением.
Где-то тащат (аплайансы типа банкоматов), но ты у себя ведь так не делаеш?
Pzz> Причем без предупреждения.
Насколько без предупреждения? Если речь о замене мажорной версии системы со всеми библиотеками — то при этой замене, когда идёт проблема, всегда предупреждают: надо пересобрать, у нас отменена libvasya, применяйте libpetya или тащите libvasya с собой.
Если о минорах — то не должно несовместимо меняться.
Но польза от закрытия дыр и багов в стандартных библиотеках до сих пор заметно превышала недостатки такой возможной несовместимости.
Здравствуйте, GhostCoders, Вы писали:
GC>Я к тому, что Linux и Windows — разные миры. В Linux все библиотеки используются из стандартных пакетов, в Windows — обычно все тащат с собой, свое. GC>Но в Linux есть проблема разных дистрибутивов (не всегда в нужном дистрибутиве данный пакет будет присутствовать в списке стандартных, часто присутствует, но все же бывает GC>иногда и нет), еще и GLIBC часто присутствует один для всех программ и он системный.
Есть ещё такие [censored], как snapʼы. Я вот на VScode посмотрел — он тащит за собой весь юзерланд, включая libc.
Здравствуйте, Pzz, Вы писали:
Pzz>Основной недостаток динамических библиотек — это то, что либо у тебя программа распостраняется вместе со всеми своими библиотеками, и тогда нет смысла делать их динамическими
Почему? Среди возможных причин: плагины и лицензии.
Pzz>или всегда есть риск, что какое-то сочетание версии программы с версией библиотеки будет не работать. Причем без предупреждения.
А где в реальности кроме линуха есть такое?
(тоже закрытая).
солянка из so/dll разных компиляторов, часть я даже и не слышал вообще 
в зависимости от платформы, но легко (пока) решается тем, что врапперы делаются над чистым С, плюсами тами и не пахнет, боли не хочется.
