Комментарии 92
> Ничего хорошего из этого не вышло.
а можно подробности?
основной идеей было начиная с C++11 запретить реализовывать std::string как copy-on-write строку, а также стандартизировать SSO(small string optimization), что конечно же ломало ABI строки.
Часть изменений, которые назвал автор статьи, влекут поломку не только ABI, но и API (смешались в кучу люди, кони). Поломка первого почти болезненна, переход занимает всего лишь лет 5. Поломка второго неизбежно фрагментирует плюсы так же, как когда-то питон, когда язык по сути разделился на два параллельно существующих по сей день.
Если не подготовить способы внедрять изменения безболезненно, сообщество столкнется с тривиальнейшей проблемой: потом придется менять еще раз. И не единожды. А переписывать код до бесконечности любят не только лишь не все.
И тем не менее, Python 3 продолжает развиваться и преобладает по сравнению со 2-ымон не так давно начал преобладать
поддержка которого к слову уже закончилась вместе с началом 2020 годада да, а для работающих на втором питоне сервисов поменялся разве что таймстамп
По сути сейчас все оставляют как есть в угоду компания со своими древнейшими жирными монолитами кода, а из-за этого страдают новые проектыне так просто. Есть у вас какой-нибудь проект на линуксах, который использует 100500 библиотек. Вот чтобы перевести его на новый стандарт с поломкой ABI нужно не только пересобрать ваш проект, но и чтобы все мейнтейнеры пересобрали и выложили эти 100500 библиотек. И если хоть одна из этих либ будет проприетарной, вам придется ждать пока эта контора обновит библиотеку. Если вообще когда-либо обновит.
P.S. Вот здесь собственно проблема и все варианты ее решения (которые «оба хуже») уже обозначены.
Сначала добавление префикса "co_" без какой бы то ни было веской причины, теперь отказ от такой очевидной вещи, как возможность смены ABI в мажорном релизе и снова без веских на то причин… Всё это как минимум не выглядит разумным.
Решением части проблем с ABI было бы возможность обращаться к данным класса через указатель, тогда бы и разметкой класса был всего лишь этот указатель. Идея очень близка к идиоме PIMPL, которая активно используется в Qt из-за его ABI.
К слову, Qt ломает ABI каждый мажорный релиз. Никто от этого не умер.
А так, от stdlib для бОльшего количества разработчиков не хватает на самом деле самых простых вещей — networking, простой в использовании async, тот же regex удобный, для библиотекарей — наверное комфортные концепты для templates, может даже математики векторной/матричной завернуть тоже, комфортный multithreading/multiprocessing… и что-бы все было гарантировано кросс-платформенное и из коробки.
Тонкие материи пусть обсуждают и принимают хоть до 3-го пришествия, но то что есть сейчас в приличных языках, почти из коробки, должно быть уже сегодня в C++.
* «Сделать ассоциативные контейнеры (намного) быстрее» — нет, не «намного»! Предложенные изменения для стандартных контейнеров ломают в первую очередь API, потому что они убирают методы для работы с нодами и итерации по корзинкам.
* «Ускорить работу std::regex (На данный момент быстрее запустить PHP и выполнить на нем поиск по регулярному выражению, чем использовать стандартный std::regex)» — основное что тормозит в std::regex, это локали. Убрать локали — это изменение API а не ABI.
* «Некоторые изменения в std::string, std::vector, а также в разметке других контейнеров» — скорее всего речь идёт про добавление SSO в vector, а это прежде всего ломает его гарантии по инвалидации итераторов. То есть это опять слом API а не ABI.
* «Единство интерфейса классов: на данный момент некоторые их реализации намеренно не соответствуют единому интерфейсу в угоду стабильности ABI» — да, это осознанное решение одного единственного вендора. И что бы не решил в этом месте комитет — это личное дело вендора, когда именно ломать ABI. Планы комитета стандартизации, которые пойдут в разрез с планами вендора, будут проигнорированы. Ибо от ABI зависит бизнес вендора и его финансовое благосостояние.
* «Предложение добавить фильтр в recursive_directory_iterator было отклонено, потому что сломало бы ABI» — оно было отклонено, потому что оно дурное. Автор предложения неправильно написал бенчмарк, что сводило полезность и достоверность его предложения на 0.
* «Предложение сделать большинство функций из библиотеки constexpr (включая strlen) скорее всего тоже будет отклонено, ведь ломает ABI» — это можно реализовать без слома ABI. Комитет отправил нас исследовать этот вопрос, мы поисследовали, всё ОК.
Ну и в целом: голосование решило что форсить слом ABI не будем, потому что вендоры могут не поддержать; голосование сказало что при наличии достойной идеи ломать ABI — это ОК. Трагедии особой не вижу. Единственная проблема — голосование получилось нейтральным, из-за этого противники и сторонники слома одинаково недовольны.
да, это осознанное решение одного единственного вендора.
А можете намекнуть, что это за вендор?
Разумеется можно сломать ABI, но тогда коммерческие продукты вынуждены будут либо
* собирать только под новый ABI, и забросить поддержку старых платформ
* собирать только под старый ABI (потому что он везде поддерживается), и тогда новый ABI немного теряет смысл.
* собирать под новый и старый ABI, что они навряд ли захотят делать
А можете пояснить вот такой момент: для той же visual studio статическую библиотеку приходится собирать под 4 версии стандартной библиотеки ((дебаг + релиз) * (однопоточная + многопоточная)). И для каждой версии компилятора (2013, 2015 и т.д.) свой набор ещё конечно же.
Я верно понимаю что GCC сохраняет совместимость на том уровне, что собранное статическое чудо условно версией 4.0 будет работать без проблем с версией 5.0, с другой соответственно реализацией стандартной библиотеки, другими "фишками" компилятора и т.п.?
Или какие-то ограничения есть?
Всё-таки неясно, в чем отличие от обычной ситуации с библиотеками: например, в debian часто в рамках одного дистрибутива бывает несколько версий одной библиотеки. Понятно, что если слинковаться с несколькими одновременно и передавать объекты, то будут проблемы.
Почему здесь, если поступить также и сделать две stdc++, то ожидаются непреодолимые трудности?
Добавлю к списку:
- "Создание неявных виртуальных деструкторов для полиморфных типов"
Плохая идея сама по себе, даже если бы не требовала слома ABI. - "возвращаемый тип у push_back может быть изменен, если сломать текущий ABI"
Можно поменять и не ломая ABI, как это сделали в C++20 дляstd::list::remove. - "А вообще, действительно ли нам нужен и push_back, и emplace_back?"
Объединить их можно было бы, но тут надо опять говорить об API а не ABI.
PS: у нас на проекте своя реализация стандартной библиотеки (и не только ее. не спрашивайте), так что я на это все смотрю с попкорном. Лично я бы начал с того, что добавил способ спросить функцию в либе (хоть статической хоть динамической) — с какой ABI она умеет работать. А потом уже там все улучшал.
А, ну и C++, который мы потеряли. Все как обычно.
А кто первый предложил перейти на "std42::", т.е. тупо использовать разные неймспейсы для новых ABI?
Пардон, но как могут быть те же проблемы с новыми именами. Кто мешает ломать совместимость каждые 10 лет в новом std:: ?
Не могу согласиться.
Это не проблемы, а неизбежное следствие развития.
Как мне кажется, при наличии std11::, std14::, std17:: и std20:: обсуждаемой проблемы ABI просто не было-бы. Но возможно я тупо не в курсе какой-то общеизвестной причины? antoshkka?
И?
Рано или поздно придется что-то менять с нарушением совместимости.
При этом я бы предпочел явно видеть все подобные изменения и иметь возможность совмещать старый и новый код.
Поэтому я не вижу другого решения и не понимаю почему решили отрезать кошке хвост частями.
Лично мне больше нравится вариант "хочешь новую клёвую структуру данных — обзови её по-другому". Суть та же, но выглядит не настолько радикально.
хочешь новую клёвую структуру данных — обзови её по-другому
конвертировать эти stdXX туда-сюда
Все никак не могу понять: если сломать ABI, то какой смысл оставаться на С++?
Буквально на днях (в рамках "олимпиады" посвященной переписыванию wc) в очередной раз стало понятно что компиляторы разных языков выдают примерно одинаково работающий бинарь.
P.S. Я не против плюсов и своей профессиональной деятельности использую 2 языка: С++17, Python27.
Ну да, появление LLVM дало быстрые компиляторы очень многим языкам, и сейчас наверное уже не обязательно учить плюсы, чтобы писать довольно быстрые программы. С другой стороны, зачем тем уже кто знает С++ куда-то уходить? Просто ради того чтобы уходить?
Ради новых концепций, которые в плюсах не заложены (при этом иногда реализованы, но через костыли).
Да всё равно подвезут раньше, чем я успею освоить другой язык на таком же уровне. Ну и через стороннюю библиотеку можно много чего заложить довольно глубоко, напр. как метапрограммирование или сопрограммы в boost.
Ну вот, к примеру, сопрограммы "подвозили" в язык 8 лет. Те, кто ушёл в другие языки — давно уже успели эти другие языки освоить, а то и забыть.
Насчёт «успели освоить» — я думаю, вы выдаёте желаемое за действительное; время, требующееся на освоение языка, очень нескоро отобьёт преимущества сопрограмм или любых других вещей.
Я уже пару лет активно пишу на Питоне (хотя и нерегулярно, да и в основном всякую мелочь), но всё равно постоянно ныряю в документацию и в целом чувствую себя гораздо менее комфортно, чем в C++.
Те "сопрограммы", которые в бусте, слишком прожорливы в плане памяти и переключаются не так быстро.
Проблемы у зелёных потоков общие для всех языков: чтобы они не были прожорливы по памяти, им нужен сегментированный стек. А сегментированный стек автоматически означает неполную совместимость с другими языками по ABI.
У встроенных же сопрограмм никаких особых сложностей нет, кроме необходимости их реализовать.
А вообще, действительно ли нам нужен и push_back, и emplace_back?
Хм… А если конструктор приватный, как элемент в коллекцию с помощью emplace_back засунуть ?
Будущее за Rust
Понятно. Будущее за RustСорвали с языка )) Если идет переписывание ABI, то почему бы не создать новый С+++ без обратной совместимости и без ошибок прошлого.
На моей памяти "убийц C++" уже много понасоздавали, "без обратной совместимости и ошибок прошлого". Но что-то у них с "убийством" не заладилось — есть мнение, что не в последнюю очередь из-за наплевательского отношения к "обратной совместимости", не позволяющей полноценно использовать огромную массу уже наработанного качественного кода, а также неизбежным привнесением новых граблей в процессе выполнения этапа "мы наш, мы новый мир построим". Так что поживём-увидим.
Можно писать «небезопасные» секции с прямой работой с памятью и другими плюшками.
На моей памяти «убийц C++» уже много понасоздавали...Это не значит, что у любого следующего не получится.
Или может, мне не стоит использовать C++ в принципе?
Сам факт существования множества библиотек (например части того же Qt), частично или полностью заменяющих стандартную, вопиет о недостатках и недоделках стандартной библиотеки.
Поэтому да, ломать ABI (и пожалуй API тоже, но с умом). С ABI, пожалуй, всё ясно — открытые исходники просто пересобираются. С закрытыми всё относительно плохо, но если выбирать, либо развитие, либо смерть, то выбор очевиден. Нет, конечно, полностью C++ не умрёт, как не умер FORTRAN, но стагнация и потеря популярности неизбежна. Важно только при изменении ABI сделать следующее такое изменение (а оно тоже неизбежно), менее болезненным.
Другое дело, как влияют на принятие решений комитетом те, кто заинтересован в заморозке ABI. Ведь понятно, что множество корпораций и фирм готовы принести C++ в жертву своим сегодняшним прибылям и выгодам. И их сегодняшние сиюминутные выгоды могут перевесить потери вызванные стагнацией языка. Но это лишь говорит о том, что если не поменять ABI сегодня, завтра это будет сделать ещё сложнее (== невозможно).
День смерти стандартной библиотеки