Черновик стандарта C++26 официально отклонён

Ну, норм. Ребята работают.

Они как бы проголосовали за остановку развития C++. Дидов явно нетуда понесло.

ну, не совсем. Контракты были давно на очереди в принятие, их чуть ли не к C++20 уже хотели завершить. Но раньше предложенные решения контрактов отклонялись раньше финального голосования. Чтобы финальное голосование провалить - это, как я понял, впервые с C++.

Вместе с контрактами, вроде как, повисла также и compile-time рефлексия.

Новость прекрасная.

не набрав минимальные соотв. 2/3 «за» и максимальные 25% «против».

не набрав минимальные соотв. 2/3 «за» и набрав максимальные 25% «против».

так?

да, пардон, спешил на ЛОР сообщить, язык заплетался…

Вроде не видел тут этой новости.

Мне что-то лень в development вбрасывать. Срачей на 30 страниц не предвидится, а значит нет смысла писать.

Кек, Stand-Art

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

Плюсы как всегда.

А нафига эти контракты сдались? Вот я смотрю пример с банковским счётом, где баланс выносят на контракты. Так ты сделай отдельный класс Баланс и заложи в него всю логику арифметики (переопределив арифметические операторы).

Ну, или давайте нормальные примеры, где оно реально нужно. В той же джаве, кстати, в методе вызывают статичные методы (стандартные из JDK requireNonNull и вот это всё) на определенные проверки, если уж нужно без ифов.

Что ты хочешь от толп деформированных людей? Чтоб ровно стояли? Нет, будут кривые и ещё толпы других согнут.

А ещё мне чатгпт выдаёт такие примеры:

        require
            valid_key: not key.is_empty
        do
            -- Добавление элемента
        ensure
            has_key: has (key)
            correct_value: item (key) = value
            count_increased: count = old count + 1
        end

Складывается впечатление, что у них в 80-х ЕСС памяти не было. Или это реально нужно делать на очень важных данных, двойную перепроверку? Опять же в тестах часть эти контрактов проверяется.

Хотя черновик спецификации контрактов для C++26 определяет варианты реакции на нарушение контрактов (ignore, observe, enforce, quick-enforce), какая именно выбирается, зависит от реализации

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

А вот эта идея выглядит интересной:

class interface DICTIONARY [G]

feature

    put (key: STRING; value: G)
        require
            valid_key: not key.is_empty
        ensure
            has_key: has (key)
            correct_value: item (key) = value
            count_increased: count = old count + 1
        end

    item (key: STRING): G
        require
            key_exists: has (key)
        end

    has (key: STRING): BOOLEAN

    count: INTEGER

invariant
    non_negative_count: count >= 0

end

Фактически из неё можно тесты генерить.

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

Да, я уже понял, что это больше относится к интерфейсной части, а не к реализации. Интересная идея.

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

А раньше такое случалось когда-нибудь, что черновик отклоняли? Ну, при принятии прошлых стандартов.

Я так понял, что, естественно, отклоняли. Но не на такой поздней стадии в процессе принятия.

Почитал про контракты. Хрень какая-то. Можно просто ифами тоже самое сделать. Компаил тайм рефлексия это говно говна. Цпп развивается в никуда. А точнее туда, куда нужно тем, кто спонсирует комитет, что грустно.

Можно просто ифами тоже самое сделать

Нельзя.

Привели пример, что нельзя?

Предлагаю вооружить всех участников конфликта.

одним водку, другим коньяк?

Ну как ты соберёшь проект в версии без энфорсинга контрактов простым изменением одной настройки (флага компиляции). Без костылей типа препроцессора или своих собственных (что ещё хуже)?

Не заслужили.

простым изменением одной настройки (флага компиляции). Без костылей типа препроцессора или своих собственных

/0

Чем тебя препроцессор/свои костыли не устроили?

У препроцессора слишком примитивная семантика «вставлялки текста». Практичность в задачах портирования кода, - типа когда надо «вбросить» или условно скомпилировать код в один конкретный набор аппаратных инструкций - оправдывает его существование. Или ещё второй юзкейс - когда надо создать тонкую обёртку над сишной функцией с va_arg - тут он тоже удобен.

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

Я не понял этот набор слов. Я напишу тоже самое ифами в коде.

В тестах проверяются частные случаи выполнения кода, а контракты действуют всегда.

Впрочем, по-моему они ассерты переизобретают, отличие тут только в том что они вынесены в объявление функции. Могли бы название «ассерт» и оставить, чтобы никого не путать.

двойную перепроверку?

У меня иногда и тройные получаются, если развернуть стек вызовов. Это скорее защита от опечаток и прочих багов, код может меняться доработками, а ассерты должны соблюдаться всегда, изменение ассерта можно более внимательно анализировать. Ловля ошибок памяти - тоже приятный бонус (впрочем, память может побиться и по програмным причинам, от которых ecc не спасёт).

Не ифами а ассертами.

Да и ими тоже, но можно вызывать std::terminate() в теле ифа

Зачем заново реализовывать ассерт, когда можно просто одно слово написать? И не terminate а abort - дамп пригодится в выяснении откуда взялся баг.

Я даже без нужды в if-ах видел конструкции вида assert(!«описание-проблемы»); (например в конце функции куда не должно попадать исполнение или в недопустимом case switch-а. Потому что assert из коробки делает удобное падение от ошибки с логированием.

Контракты в плюсах - это ещё одно ненужно наряду с модулями, ренжами, std::simd и что там ещё есть.

Статическая рефлексия в теории безусловно нужна, но то как ее реализовали на практике (нахардкодили там всяких std::vector) - это просто идите нахрен.

Так и живём.

а что не так с модулями и ренжами?

Контракты можно на этапе компиляции проверять.

Ну и чтобы два раза не вставать

Фактически из неё можно тесты генерить.

Это делать зачастую не за чем, т.к. контракт уже проверяет это.

И не terminate а abort - дамп пригодится в выяснении откуда взялся баг.

std::terminate тоже делает raise(SIGABRT).

% printf '#include <exception> \n int main() { std::terminate(); }\n' > foo.cpp
% g++ -Wall -Wextra foo.cpp -o foo
% strace ./foo |& tail -10
futex(0x7f45510ac87c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
brk(NULL)                               = 0x55a47ba21000
brk(0x55a47ba54000)                     = 0x55a47ba54000
write(2, "terminate called without an acti"..., 45terminate called without an active exception
) = 45
gettid()                                = 1247118
getpid()                                = 1247118
tgkill(1247118, 1247118, SIGABRT)       = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=1247118, si_uid=1000} ---
+++ killed by SIGABRT +++
zsh: abort      strace ./foo 2>&1 | 
zsh: done       tail -10
%

Правда, он какую-то лишнюю ерунду печатает, если его просто так (без «текущего исключения») вызвать.

Контракты - это не только ценный мех проверка условий, но ещё и спецификация.

Что-то я не понял, как реагировать. Контракты с одной стороны штука полезная, с другой, вот это:

определяет варианты реакции на нарушение контрактов (ignore, observe, enforce, quick-enforce),

Я вообще не понял. Зачем нужны контракты, которые не контракты.

Короче, очень интересно, но нифига не понятно.

Ну это как assert. Там тоже два поведения и определяется через define. Тут решили сделать assert на стероидах.

ну ренжи кстати используются

у assert’а есть одна проблема - он не всегда работает нормальные люди сами пишут макросы для этого

Он может не работать если его препроцессором отключили. Или есть ещё какие-то причины? Эти контракты тоже предлагается уметь отключать, и в целом для тех же нужд что и ассерты (надеемся что в проге нет багов и хотим выгадать несколько производительности на этом основании).

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

Ну как ты соберёшь проект в версии без энфорсинга контрактов простым изменением одной настройки (флага компиляции). Без костылей типа препроцессора или своих собственных (что ещё хуже)?

А что полохго в

#define ASSERT(x,y) if((x)){ (y);}

а что не так с модулями и ренжами?

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

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

То же самое модули. Заявляется что это типа для повышения скорости компиляции, а также чтобы оттуда не утекали дефайны. При этом под капотом модули - это по сути PCH. Что мешает использовать напрямую PCH - науке неизвестно. Что мешает делать undef дефайнов - науке также не известно.

В реальности все эти «фичи» получаются из-за того, что в бигтехе типа гугла и прочих «корпораций добра» сначала нанимают по квотам и знакомствам всяких бездарей на позиции манагеров, а потом ставят им KPI «придумать проект и пропихнуть его куда-нибудь там». Ничего реального и полезного эти бездари придумать не могут, потому ищут проекты, где можно наговнокодить так чтобы с них за это не спросили. В плюсах вообще идеально - там комитет, на который всегда можно всё свалить.

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

В реальности все эти «фичи» получаются из-за того, что в бигтехе типа гугла и прочих «корпораций добра» сначала нанимают по квотам и знакомствам всяких бездарей на позиции манагеров, а потом ставят им KPI «придумать проект и пропихнуть его куда-нибудь там». Ничего реального и полезного эти бездари придумать не могут, потому ищут проекты, где можно наговнокодить так чтобы с них за это не спросили. В плюсах вообще идеально - там комитет, на который всегда можно всё свалить.

Ну, если конкретно про гугл речь, то это как раз плохой пример, ведь именно там появился более простая, чем плюсы, Гошка… Т.е. даже наоборот, типа «ударяем и по ООП, и по сложным спекам старперных языков! Серпом им всем по яйцам! Да здравствует Гошка!»

При том когда появилась, хайпанула на все деньги. Может подход и был верным.

Go это как раз крайне показательный пример того что делает гугл.

Когда-то давно там выделяли сотрудникам 20% времени на персональные проекты. Go был запилен местными ветеран юникс админами по собственной инициативе именно в эти 20%.

Потом Go набрал популярность, для его разработки в гугле выделили команду и назначили манагеров. И понеслось.

Сначала в Go сторонние зависимости задавали, если грубо, просто по урлу репозитория, это была полностью децентрализованная система. И доки генерились прямо на лету командой go doc. Нехорошо. В гугле запилили и включили по дефолту go module proxy - т.е. go для скачивания зависимостей идёт на гугловую инфраструктуру и скачивает оттуда. А гугловая инфраструктура в фоне долбит настоящие репозитории, непрерывно всё оттуда клонируя.

А чтобы юзеры не отключали и не банили эту хрень, в гугле запилили проприетарный https://pkg.go.dev/ - если владелец репозитория забанит у себя гугл, то никакой документации про его пакеты на этом сайте не появится.

Затем манагерам не понравилось, что стандартная библиотека Go слишком качественна и стабильна. То есть в неё ничего просто так уже не запилишь, надо думать и разбираться, а они не умеют. Что делать? Правильно, вкорячили туда нафиг никому не упавшие дженерики, и объявили что переводят стандартную библиотеку на них. В результате - практически бездонный источник тасок с майлстоунами, вон растоманы со своими трейтами не дадут соврать.

На самом деле контракты в плюсах - это фича ровно из той же серии что дженерики в go. Позволяет до бесконечности что-то там пилить в кодовой базе без видимых последствий для пользователя, на вопрос «нахрена» отвечая «для безопасности». А если бесконечность всё-таки закончится, то всегда можно нафигачить в стандарт новых контрактов - заодно и строчка в резюме «участвовал в разработке нового стандарта C++», просто идеально.

ЗЫ Кстати еще мякотки про go module proxy.

I committed a new change (or released a new version) to a repository, why isn’t it showing up when I run go get -u or go list -m –versions?

In order to improve our services’ caching and serving latencies, new versions may not show up right away

и лицо кирпичом, типа все нормально, так и надо. При том что 95% проектов на Go размещено на github. Предлагаю гугломанагерам пойти в мелкософт и начать рассказывать, что у него что-то там не так с caching и serving latencies. До такой степени что пришлось пилить прокси.

В гугле запилили и включили по дефолту go module proxy - т.е. go для скачивания зависимостей идёт на гугловую инфраструктуру и скачивает оттуда. А гугловая инфраструктура в фоне долбит настоящие репозитории, непрерывно всё оттуда клонируя.

Это именно то, что все солидные люди в своей рабочей инфраструктуре стремятся создать. Чтобы условный «pip install» (или что там аналогичное в гошке) не лез каждый раз на общий всемирно-колхозанский-опенсорс-сервер, - в котором какой-то контрибьютор важного пакета внезапно пролюбил свои ключи от гитхаб - а чтобы тянуть конкретные версии зависимостей с внутреннего сервера пакетов типа artifactory, в котором специально настроенные агенты будут автоматом шерстить бинари на предмет известных уязвимостей и предупреждать об этом коллектив заранее. И на которых зловред не попадет просто хотя бы по причине временного лага между обнаружением его в апстриме и скачиванием из апстрима на внутренний сервер новой версии пакета (если она, эта новая версия пакета, вообще нужна для конкретного бизнеса).

А что до усложнения гошки… Ну да, есть такое, но ведь это со всеми ЯР происходит.

Это именно то, что все солидные люди в своей рабочей инфраструктуре стремятся создать. Чтобы условный «pip install» (или что там аналогичное в гошке) не лез каждый раз на общий всемирно-колхозанский-опенсорс-сервер, - в котором какой-то контрибьютор важного пакета внезапно пролюбил свои ключи от гитхаб - а чтобы тянуть конкретные версии зависимостей с внутреннего сервера пакетов типа artifactory

вот только гугл ничего подобного не запиливал. Его go module proxy - это полностью проприетарная, включенная для всех по дефолту хрень, которую не поднимешь на своей инфраструктуре.

Собственно почему «типа» - artifactory насколько я понимаю поддерживает go модули. И другие подобные проекты тоже есть, типа gomods. Но это все сторонние проекты, не имеющие отношения к гуглу.