Cpu abi несовместимо как исправить

Все в порядке, но.

Этот текст мало кто будет читать и мы можем написать здесь все, что угодно, например.
Вы живете в неведении. Роботы уже вторглись в нашу жизнь и быстро захватывают мир, но мы встали на светлый путь и боремся за выживание человечества. А если серьезно, то.

В целях обеспечения безопасности сайта от кибератак нам необходимо убедиться, что вы человек. Если данная страница выводится вам часто, есть вероятность, что ваш компьютер заражен или вы используете для доступа IP адрес зараженных компьютеров.

Если это ваш частный компьютер и вы пытаетесь зайти на сайт, например, из дома — мы рекомендуем вам проверить ваш компьютер на наличие вирусов.

Если вы пытаетесь зайти на сайт, например, с работы или открытых сетей — вам необходимо обратиться с системному администратору и сообщить, что о возможном заражении компьютеров в вашей сети.

Технический

Обсуждение технических вопросов связанных с игрой. Не запускается игра, проблемы с графикой, нет коннекта, сколько кушает и т.д.

Подфорумы

EVE Mac

Играем на платформе Apple.
Тем: 66 / Ответов: 977

Утилиты, приложения и ресурсы

Обсуждение программных ресурсов созданных для игры, различных утилит, программ, программных кодов и прочего, что попадает под определение software.

Тем: 276 / Ответов: 10267

Недавно обновленные
По дате создания
Самые обсуждаемые
Самые просматриваемые
Настроить
Показать не/отвеченные

Показать темы с ответами
Показать темы без ответа
Показать все темы

Проблема несовместимых API или как легко поддерживать совместимость с OpenGL, DirectX и Vulkan

В программировании очень популярен прием создания программных интерфейсов — API. Этот прием очень полезен, чтобы скрыть все тонкости реализации и не нагружать ими обывателя. Но бывают случаи, когда хотелось бы поддерживать в коде несколько API, которые выполняют одну и ту же задачу, причем с минимальным переписыванием кода. Например: поддерживать работу игры (движка) на различных графических API: DirectX, OpenGL, Vulkan. В данной статье представлены мысли о том как это сделать.

Описание проблемы

Рассмотрим пример: Вы хотите написать кроссплатформенный игровой движок. Допустим вы знаете С/С++, OpenGL, DirectX, Vulkan. Поскольку движок кроссплатформенный, то вы сначала думаете «а сделаю ка я его на OpenGL», и все то у вас хорошо получается, пока к вам не закрадывается мысль, что может OpenGL не идеально подходит для windows? Почему то же крупные компании делают поддержку сразу всех API, и UnrealEngine под windows собирает с использованием DirectX (по умолчанию), а не OpenGL/Vulkan. И вот перед вами стоит задача — как-то обобщить все API. Вы пытаетесь написать интерфейс — IRenderer и классы потомки, которые бы сами инициализировали требуемый API и отвечали за рисование. Но вот не задача, OpenGL не может работать без созданного окна (скрытое окно тоже окно), а DirectX и vulkan могут. И решения тут два: либо делай IRenderer так, чтобы он отвечал и за создание окна (дополнительная ответственность у классов), либо привязывай IRenderer к какому-то окну уже созданному (но ведь можно же рендерить без окон. Не универсально!!). В общем сходу так и не продумать IRenderer, слишком API не похожи друг на друга, хотя казалось бы решают одну и ту же задачу — доступ к видеокарте и обеспечение рисования. Но написать игру все же хочется и хочется чтобы она работала под разными платформами, с разными несовместимыми API, а еще хочется чтобы код был читабельным, минимальным и не переписывался по 10 раз. На этот вопрос я и постараюсь ответить.

Таким образом, несовместимые API — это API, которые решают одну и ту же задачу, но имеют совершенно разные подходы к решению и следовательно разный набор функций. Подходы настолько разные что не получается обобщить работу под одним интерфейсом. А совместимые API — это API, которые состоят из похожих функций (сигнатуры похожи). Примеры совместимых API: сокеты, потоки, кучи памяти, файлы. Их работу легко обобщить под одним интерфейсом и поэтому так много библиотек для работы с ними написано.

Предлагаемое решение

А решение простое: обобщать не API, а приложение. Прикладной код приложения (игровая логика, физика, ИИ, GUI, и пр.) — оформляется в виде отдельной библиотеки с определенным интерфейсом. Пример объявления библиотеки:

template class IGame < public: virtual ~IGame()<>//функция обработки одного такта игры virtual OutputData Tick(const InputData& input) = 0; >;

#include "IGame.h" // Коды клавиш для внутриигровой обработки enum KeyCode < KEY_UNKNOWN, KEY_ESCAPE, KEY_W, KEY_A, KEY_S, KEY_D, //. KEYS_TOTAL >; //Возможные коды ошибок игры enum ErrorCode < ERROR_UNKNOWN, //.. ERRORS_TOTAL >; //Управляющие команды игры enum CommandCode < COMMAND_UNKNOWN, COMMAND_CLOSE_GAME, //. COMMANDS_TOTAL >; //Входные данные по которым игра обрабатывает один свой такт struct InputData < float ProcessTimeInSec; float CursorPos_x; float CursorPos_y; bool PressedKeys[KeyCode::KEYS_TOTAL]; //. >; //Выходные данные такта игры struct OutputData < std::vectorСommands;//команды такта игры std::vector Уrrors;//ошибки такта игры std::vector VertexBuffer; //вершинный буфер, который заполняется //при просчете такта игры int VerticesCount; //кол-во вершин //. >; // реализация интерфейса прикладной библиотеки class Game : public IGame < public: //Инициализация игры Game(/*Сюда можно вставить параметры игры*/); //Деструктор освободит ресурсы игры virtual ~Game(); //функция обработки одного такта игры virtual OutputData Tick(const InputData& input) override; >;

Итак вы реализуете класс Game, пишите игровую логику, делаете это максимально кроссплатформенно и не привязываясь к определенным низкоуровневым API. Через структуру OutputData возвращаете данные геометрии, данные оцифрованного звука, желательно управляющие команды и ошибки.

UDP: Код представленный в статье лишь пример и модель, его цель объяснить идею, а не эффективно выполнится, поэтому я опустил различные оптимизации.

Дальше надо написать функцию main. Именно функция main и вызывает конкретные функции OpenGL/DirectX/Vulkan попутно вызывая код вашего приложения через функцию Tick. Из функции Tick возвращаются данные, которые конкретное API может использовать для рендеринга, воспроизведения звука и т.д. Общий код функции main может быть таким:

//#include ///. //#include ////. #include "Game.h" int main() < //код по открытию окна Window wnd = openWindow(. ); //назначить обработчики событий нажатия клавиш и движения мыши в wnd wnd.SetCallback(. ); //инициализация графического API InitializeGraphicAPI(. ); //также нужно сделать отображение кодов клавиш низкоуровневого API //в коды клавиш вашей прикладной библиотеки. Game::KeyCode KeyMap[Api.KeysCount()]; KeyMap[Key_Escape] = Game::KEY_ESCAPE; //. //создание игры Game game; //входные данные для просчета одного такта игры Game::InputData input;//не забудьте их заполнить начальными значениями //главный цикл приложения while(wnd.IsOpen()) < //вызываем оконные события wnd.pollEvents(); //заполняем вводные данные для такта игры input.Time = . ; input.CursorPos = . ; input.PressedKeys = . ; //просчитываем один такт игры //можно поиграть с многопоточностью и запускать просчет такта в новом потоке Game::OutputData output = game.tick(input) //вывод renderingWithApi(output); PlaySoundsWithApi(output); //. >return 0; >

Под каждую конфигурацию нужно написать свой main, который связывается с кодом вашей прикладной библиотеки.

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

Заключение

Что это все дает?

Переносимость кода под любые API с минимальным переписыванием кода,
Ускорение темпа разработки, потому что можно очень много времени потратить на проектирование интерфейса IRenderer, а затем на дописывание/переписывание,
Спорный плюс: если оформить вашу прикладную библиотеку в виде dll, то можно подключить эту dll в собственный main и выполнить портирование программы на API, которые использует ваша система. Но к сожалению формат dll не стандартизирован и не переносим с одной платформы на другую.

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

Важно: данный подход стоит применять только в случае несовместимых API. Когда API совместимы (сокеты, потоки, менеджеры памяти и все что работает примерно одинаково), то лучше сделать интерфейс для API, а не приложения.

Честно, я не знаю каким решением пользуются крупные компании вроде EpicGames. Возможно с их количеством экспертов по всем областям программирования они могут продумать и спроектировать интерфейс IRenderer. Но я не думаю что это под силу небольшой группе программистов, которые далеко не эксперты в применении низкоуровневых API. Если у кого-то есть информация о том, как это делается в крупных и не очень компаниях, то я буду рад, если вы скинете это в комментариях.

Мне известно, что Dear ImGui и Nuklear используют аналогичный подход — основная логика выделена в отдельный модуль и есть ряд бэкендов (под каждую конфигурацию и без единого интерфейса), которые отвечают за вызов функций графического API или оконного API. Но их код не такой прозрачный и понятный, как я показал выше.

P.S.

Дабы продемонстрировать работоспособность решения, я собрал небольшой проект на GitHub — приложение которое создает окно и выводит разноцветный треугольник. Опять же цель проекта — объяснить идею, а не создать эффективную программу, поэтому код не везде оптимален.

День смерти стандартной библиотеки

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

Что такое ABI

ABI — набор соглашений, определяющих, как ваша программа представляется в бинарном виде, как в ней объявляются имена, задается разметка у классов и определяются соглашения о вызове функций. По сути, это своеобразный двоичный протокол, однако он не является версионным.
Чтобы не запутывать вас в терминологии, давайте рассмотрим на примерах, что влечет за собой изменение ABI и его поломка в рамках программы:

Вы не сможете использовать экспортируемый символ в новой версии вашей скомпилированной библиотеки, если вы сделали что-либо из нижеперечисленного:

Добавили новое поле в уже существующий класс
Поменяли шаблонные параметры у класса/функции, превратили шаблонную функцию в нешаблонную или наоборот, добавили variadic template
Применили спецификатор inline к чему-либо
Добавили параметры по умолчанию в объявлении функции
Объявили новый виртуальный метод

Почему мы должны сломать ABI

Прежде всего, есть несколько полезных изменений в реализации стандартной библиотеки, которые можно внедрить, если нарушить текущий ABI:

Сделать ассоциативные контейнеры (намного) быстрее
Ускорить работу std::regex (На данный момент быстрее запустить PHP и выполнить на нем поиск по регулярному выражению, чем использовать стандартный std::regex )
Некоторые изменения в std::string , std::vector , а также в разметке других контейнеров
Единство интерфейса классов: на данный момент некоторые их реализации намеренно не соответствуют единому интерфейсу в угоду стабильности ABI

std::scoped_lock был добавлен для того, чтобы не сломать ABI изменением lock_guard
int128_t не может быть стандартизирован, потому что меняет intmax_t . Однако, если бы спросили меня, я бы просто сказал, что intmax_t должен стать deprecated
std::unique_ptr мог бы храниться в регистре с помощью некоторых модификаций в языке, что сделало бы его zero-overhead по сравнению с обычным указателем
Большинство изменений для error_code были отклонены как раз из-за того, что они влекли за собой поломку ABI
status_code также вызывает проблемы с ABI
Предложение добавить фильтр в recursive_directory_iterator было отклонено, потому что сломало бы ABI
Предложение сделать большинство функций из библиотеки constexpr (включая strlen ) скорее всего тоже будет отклонено, ведь ломает ABI
Добавление поддержки UTF-8 в std::regex — поломка ABI
добавление поддержки в realloc и возврат размера аллоцированной памяти является поломкой ABI для полиморфных аллокаторов
Создание неявных виртуальных деструкторов для полиморфных типов
возвращаемый тип у push_back может быть изменен, если сломать текущий ABI
А вообще, действительно ли нам нужен и push_back , и emplace_back ?
Улучшение std::shared_ptr также влечет за собой поломку ABI
[[no_unique_address]] мог бы выводиться компилятором, если бы мы не заботились о сохранении текущего ABI

Что еще мы хотим изменить?

Я не знаю. И я не знаю того, чего не знаю. Но если бы меня попросили угадать, я бы сказал следующее:

Во время разработки модулей для C++23 мы снова столкнемся с проблемами ABI, потому что все не-экспортируемые символы должны будут оставаться в глобальной части модуля, чтобы не сломать ABI. Этот факт в принципе уничтожает весь смысл модулей как таковых
Существует очень много людей, которые уверены, что стоимость исключений может быть значительно снижена в тех местах, где хромает качество реализации, однако все это опять же скорее всего потребует сломать ABI
Дальнейшие улучшения корутин могут привести к проблемам с ABI, и их как раз можно существенно улучшить
Перемещение объектов требует явного оператора, опять же по причинам ABI
Предложения Tombstone точно приведут к проблемам с ABI

Обсуждение ABI в Праге

В течение прошедшего обсуждения ABI, в Праге был проведен ряд опросов, которые, однако, не говорят нам ни о чем. В зависимости от того, пессимист вы или оптимист, текущие результаты могут быть интерпретированы вами по-разному.

WG21 не желает ломать ABI в 23 году
WG21 считает нужным сломать ABI в следующих версиях C++ (С++26 или далее)
WG21 потребуется время на рассмотрение предложений, которые нарушают ABI
WG21 не обещает вечную стабильность
WG21 считает важным сохранить приоритет на производительность, даже в ущерб стабильности языка

Гадание по кофейной гуще

В какой версии C++ ждать изменений

Очевидный недостаток всех этих опросов заключается в том, что мы так и не определились, когда именно мы хотим сломать ABI.

в C++23? Нет, уже точно нет.

в C++26? Часть людей намерены голосовать за, но другая часть скорее всего проголосует за C++41 или за то время, когда они уйдут на пенсию и им не придется поддерживать свой текущий проект. Один из вопросов просто упоминал C++-какой-то; очень удобно!

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

Я не думаю, что в опросе, проведенном через три года что-то изменится. Это как глобальное потепление: все согласны, что нужно когда-нибудь заняться этой проблемой. А давайте тогда запретим дизельное топливо в 2070?

Все, что не планируется сделать в ближайшие пять лет, скорее всего никогда не произойдет.

О предложениях, которые нарушают ABI

WG21 проголосовало за то, чтобы уделить больше времени тем предложениям, что нарушают текущий ABI. Это означает несколько вещей:

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

Производительность важнее стабильности ABI

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

Мне кажется, комитет одновременно хочет усидеть сразу на двух стульях. А это невозможно:

Bryce Adelstein Lelbach @blebach
— Производительность
— Стабильность ABI
— Возможность что-либо менять

Выберите два варианта из предложенных.

стабильность языка и ABI в конечно счете сталкиваются друг с другом, заставляя нас задаться таким фундаментальным вопросом — Чем является C++ и чем является его стандартная библиотека?

Обычно в таком случае вспоминают термины «производительность», «zero-cost абстракции», «do not pay for what you do not use«. А стабильность ABI стоит поперек всему этому.

Далеко идущие последствия

Я глубоко убежден, что решение не ломать ABI в 23-м году — это самая большая ошибка, которую когда-либо делал комитет. И я знаю, что некоторые люди верят в обратное. Но вот что скорее всего случится в скором времени:

Кошмар обучения

Давайте будем честны. Все программы, которые полагаются на ABI, скорее всего где-то нарушают принципы ODR или используют несовместимые флаги, которые по счастливому стечению обстоятельств все еще работают.

Новые программы должны собираться из исходного кода, нам нужны инструменты, построенные на сборке из исходников, а не коллекция библиотек, которые откуда-то достали и как-то вставили в проект.

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

Отказываясь нарушать ABI, комитет открыто заявляет, что будет поддерживать плохо написанные программы на протяжении всего их существования. Даже если вы не будете линковаться с библиотеками, полученными через apt-install (которые на самом деле предназначены для системы), то другие люди будут, ведь комитет дал им на это свое благословение.

Это огромный шаг назад. Как мы можем учить других хорошим практикам языка, если для этого у нас нет никакого стимула?

Потеря интереса к стандартной библиотеке

Предполагаемая потеря в производительности библиотеки из-за нашего нежелания нарушать ABI оценивается в 5-10%. Это число будет только расти со временем. Давайте посмотрим на примерах:

Если вы — большая компания, то можете купить себе новый датацентр или платить команде программистов, которые бы поддерживали свою собственную библиотеку
Если вы разработчик встраиваемых систем, то эти 5% могут стать гранью между работающим продуктом и необходимостью купить более дорогой и мощный чип, а он может стоить миллионы
Если вы игровая компания, то эти 5-10% могут решить, станет ли ваша игра крутой или будет ли ваших пользователей тошнить от нее в VR-шлеме
Если вы трейдинговая компания, то скорее всего для вас эти проценты — успешно проведенная или проваленная транзакция

Множество разработчиков игр относятся крайне скептически к стандартной библиотеке. Они скорее разработают свою альтернативу, к примеру EASTL, чем воспользуются STL. У Facebook есть folly, у Google — abseil и так далее.

Это как снежный ком. Если люди не используют стандартную библиотеку, у них нет и интереса ее улучшать. Производительность — это тот ключевой фактор, который удерживает библиотеку на плаву. Без гарантии производительности намного меньше усилий будет приложено в ее развитие.

>> Jonathan Müller @foonathan
В чем смысл использовать контейнеры из стандартной библиотеки, если они не предоставляют лучшую производительность?

Titus Winters @TitusWinters
Возможно, потому что они распространены и легкодоступны? (эти два факта не значат одно и то же).
Голосовать за сохранение ABI это все равно что сказать, что стандартная библиотека должна стремиться быть МакДональдсом — он также есть повсюду, он стабильный и технически решает поставленные задачи.

Как комитету рассматривать предложения, ломающие ABI?

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

Добавление новых имен

Это первое и очевидное решение. Если мы не можем поменять std::unordered_map , может нам просто добавить std::fast_map ? Есть несколько причин, почему так делать плохо. Добавление типов в стандартную библиотеку обходится дорого как с точки зрения расходов на поддержку, так и с точки зрения образования. После введения нового класса неизбежно появятся тысячи статей, в которых объясняется, какой контейнер стоит использовать. К примеру, мне следует использовать std::scoped_lock или std::lock_guard ? А я понятия не имею! Мне нужно каждый раз гуглить. Также есть проблема, что хорошие имена рано или поздно заканчиваются. Еще мы получаем некоторый оверхед во время выполнения программы, так как все контейнеры должны постоянно преобразовываться друг в друга, огромное число перегрузок конвертации у класса становится трудно контролировать и т.п.

Иронично, но те люди, кто поддерживают вариант решения выше, также высказываются о том, что C++ слишком сложный язык. Добавление дубликатов в библиотеку точно не сделает его проще.

Но ведь мы могли принять это предложение в стандарт!

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

Мне, как циничному человеку, немного трудно в это поверить. Дело в том, что раньше таких предложений не было, да и сценарии, в которых они могут быть применены весьма ограничены. ABI Review Group (ARG) могла бы помочь в этом вопросе, но они скорее всего снова порекомендуют придумать другое имя для класса / функции.

Частичное нарушение ABI

Основная идея заключается в том, чтобы не ломать весь ABI, а только изменить его для определенного класса или функции. Проблема такого подхода заключается в том, что вместо ошибки на этапе линковки, мы будем видеть проблему уже во время запуска программы, и это будет неприятно нас удивлять. Комитет уже попробовал такой подход в С++11, когда поменял разметку std::string . Ничего хорошего из этого не вышло. Все было настолько плохо, что этот факт до сих пор используется как аргумент в пользу сохранения текущего ABI.

Еще один уровень индирекции

Решением части проблем с ABI было бы возможность обращаться к данным класса через указатель, тогда бы и разметкой класса был всего лишь этот указатель. Идея очень близка к идиоме PIMPL, которая активно используется в Qt из-за его ABI. Да, это бы решило проблему с членами классов, но что делать с виртуальными методами?

Рассматривая проблему с более критической точки зрения, мы говорим о добавлении еще одного уровня косвенности (индирект по указателю) и дополнительной аллокации памяти в куче для всего того, что заключено в рамках ABI. В STL, по факту, все заключено в этих рамках, потому что это набор обобщенных классов.

В итоге цена такого подхода будет огромной.

В качестве решения данной проблемы уже есть несколько предложений в стандарт. Часть из них хотят сделать PIMPL одной из фич языка, чтобы вы могли выбрать между стабильностью ABI и высокой производительностью.

Иронично, однако, но чтобы превратить библиотечные типы в PIPML-типы, нам нужно… сломать ABI.

Пересобирать весь код каждые три года

Просто мои мысли вслух.

Все текущие предложения в стандарт должны быть уничтожены

Парадоксально, но C++ никогда не был настолько живым, как сейчас. В Праге 250 человек работали над множеством вещей для него, среди которых:

Numerics
Линейная алгебра
Аудио
Юникод
Асинхронный I/O
2D и 3D Графика
Множество других фич

А потом, над горизонтом нависает такой ужас, как networking. Очень и очень безответственно пытаться стандартизировать что-либо, что может повлечь за собой проблемы безопасности, и при этом не иметь возможности это впоследствии изменить (вспоминаем про ABI).

Поскольку C++ решили сделать стабильным, все эти предложения должны быть уничтожены и сожжены. Я бы не хотел, чтобы их уничтожали, но это необходимо сделать.

Но этого все равно не сделают.

В лучшем случае, мы не наделаем ошибок и стандартизируем текущее состояние вещей в одной из новых версий C++, а затем позволим всему медленно разлагаться, так как починить это уже не будет возможности (В случае с Networking TS мы похоже не сможем вообще ничего изменить, поэтому нам придется стандартизировать то, что существовало десять лет назад. Тогда библиотеку конечно еще можно будет значительно улучшить, но давайте оставим эту историю на другой раз).

Но конечно, мы совершим еще много, много ошибок.

>> Ólafur Waage @olafurw
(Это очень хорошо сработало в прошлый раз, поэтому я попробую снова)

День добрый, твиттер программистов!

Я собираюсь выступать перед амбициозными молодыми людьми через пару недель. Какой по вашему мнению самый важный совет, который можно дать разработчику ПО (к примеру: паттерны, архитектура, алгоритмы)?

Hyrum Wright @hyrumwright
Рано или поздно любое решение, принятое во время разработки, придется изменить. Предусматривайте возможность изменения в вашей экосистеме — как в ваших инструментах, так и в самом процессе разработки.

Некоторые ошибки делаются намеренно, так как являются трейд-оффом, тогда как другие остаются незамеченными многие годы.

Время идет, но стандартная библиотека стоит на месте. Ранее сделанные трейд-оффы постепенно начинают нам мешать, а в последствие становятся настоящими «бутылочными горлышками» в существующем коде.

Часть вещей действительно невозможно изменить, так как они вшиты в API. У нас у всех есть представление о том, насколько сложно менять существующий API. Но часть кода все же может быть исправлена и улучшена, если бы мы могли сломать ABI.

C++ все еще будет на плаву в ближайшие 40 лет. Если мы не сможем осознать необходимость менять его непредсказуемым образом в любое время, то единственным верным ходом останется только не играть в эту игру в принципе.

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

Ваше предложение в стандарт будет уничтожено, мое точно также будет уничтожено.

Может ли комитет в принципе сломать ABI?

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

Но дело в том, что у разработчиков любого продукта есть свои пользователи. Пользователи — это те, кто прежде всего должен понять, какие трейд-оффы им навязаны.

Много людей полагаются на ABI совершенно случайно, не сделав осознанный выбор. Много людей также полагаются на стабильность, потому что, конечно, все хотят на нее полагаться. Но как и у любой другой вещи, у стабильности есть своя цена, и сейчас вся экосистема C++ за нее платит.