* мы сделали очень расширяемый пропозал по контрактам * но у нас нет ничего кроме рантайм чека, который мы требуем * в будущем что-то добавим (очевидно нет, если требуется рантайм чек, то никаких оптимизаций делать нельзя) И это при том, что вся стандартная библиотека (где в первую очередь должны появится контракты) просто завалена кодом, где нарушение контракта == уб
Все так боятся этого страшного UB. Иногда хочется выписать профилактическую оплеуху очередному докладчику ругающему UB. Почему то все забывают что UB полезен, это отличный способ развязать руки опимизатору. Мы же не хотим при работе с массивом постоянно выполнять проверки выхода за массив, ведь это не бесплатная операция, вот UB и решает эту проблему. В стандарте сейчас есть std::variant который не позволяет бесплатно получить содержимое, std::get и std::get_if выполняют проверку даже если автор кода точно знает что в нем храниться. Вот какой осел до этого додумался? В том же std::optional хватило мозгов сделать небезопасный оператор *.
Проверка в рантайме это чушь, полная чушь. Даже рефлексию делают статической. Как же это плохо, у языка проблема с многословностью уже сейчас в одном объявлении функции можно увидеть template const constexpr static override delete noexcept nodiscard auto, а еще какую нибудь проверку SFINAE и вариадик параметры. Уже доходит до того, что объявление функции может быть в три раза объемнее реализации. Успокойтесь наконец, хватит. Как же я злюсь, в стандарте нет ни графики ни сетей, зато куча концептов да контрактов которые никак не реализуют
@@bartolomeykant Писать обработчик. Дело в том что если требуется проверка значит нужна и корректная обработка, например бросить исключение или вернуть дефолтное значение. Если подразумевается что проверку обязуется выполнить вызывающая сторона, то глупо дублировать такие проверки. Проверки нарушения контрактов обычно выполняют упомянутым в видео assert. Если в коде нужно что-то более серьезное чем assert то на такой случай невозможно придумать стандарт, всегда будут уникальные запросы. Возможно я не правильно понял суть, или автор видело не справился и не донес идею, но то что я увидел сильно разочаровывает. Я был бы рад если бы продвигали в стандарт альтернативу макросу assert или механику позволяющую писать свои ассерты которые работали бы с модулями, но к сожалению в стандарт суют этот мусор, который отвлекает комитет от действительно важных задач. В стандарте есть отличный инструмент static_assert пусть бы развивали его, например сейчас нет простого способа вывести имя типа в лог компилятора. Обычные assert в бывают разбросанные по всему телу функции, это исключительно отладочный инструмент выполняющий роль встроенного юнит-теста, assert использует не только входные и выходные параметры а так же внутреннее состояние функции и даже глобальные данные, т.е. уже имеющийся инструмент горздо мощнее и гибче предлагаемых контрактов.
@@КошакРыжый по сути то что предлагается это asset до вызова функции, после вызова функции и можно еще несколько внутрь функции засунуть. И все это при срабатывании попадет в специальный обработчик, который один на все приложение. Для отладочных целей из этого обработчика можно напечатать стек трейс или дождаться подключения дебагерра. Больше он не зачем не нужен по сути. И этот механизм един во всем коде, какую бы стороннюю библиотеку вы не подключали. Получается вызов функции с контрактом исключает UB, так как нарушение контракта приводит к определенному поведению - крашу приложения. У меня ide мне подсказывает если я обращаюсь к значению optional без проверки, так и тут ide может предупреждать, что для вызова функции нужно сначала убедиться, что контракт соблюдается, а компилятор двойные проверки сможет оптимизировать.
Правильно нужно больше ключевых слов, а то компилятор пока не понимает нас на родном языке. Ну привели бы хоть статистику какую нибудь на сколько данный функционал востребован и кто им будет пользоваться. А то про мифические 100+ юз кейсы рассказали а кому этот функционал действительно нужен непонятно.
а с чего вы взяли что он кому-то нужен или что авторы делают его для кого-то? кто угодно может написать свой пейпер и прийти с ним в комитет. Вот люди захотели такое в C++ и они это делают. Если хотите что-то еще - вперед. Иначе слишком удобно сидеть на дивание ровно, ничего не предлагая, но критиковать людей которые прикладывают усилия чтобы что-то сделать.
@@feelamee язык программирования это не помойка куда каждый кому не лень может добавлять свои хотелки. Язык должен быть минимально достаточным, лаконичным , легким в освоение конечно если вы хотите что бы он продолжал жить.
@@GrowHobbyRU я и не говорил что каждый может добавить в C++ что захочет) Я лишь сказал что каждый может попытаться. Согласен с вашим видением языка, но для долгожителей вроде C++ это не работает. Тут всегда есть груз прошлого, который приходится тащить. Но люди стараются делать его проще и лаконичнее. По-моему - получается. И контракты эта одна из полезных фич, которую я бы хотел видеть в C++. Не знаю в таком виде или нет.
Переводить технические определения с английского на русский это ужасно. Говорите по нормальному всегда на английском. Когда говорят на русском впечатление будто вы из села или в пту программирование учили
Отличный доклад, спасибо. С языком и терминами всё хорошо и понятно было.
* мы сделали очень расширяемый пропозал по контрактам
* но у нас нет ничего кроме рантайм чека, который мы требуем
* в будущем что-то добавим (очевидно нет, если требуется рантайм чек, то никаких оптимизаций делать нельзя)
И это при том, что вся стандартная библиотека (где в первую очередь должны появится контракты) просто завалена кодом, где нарушение контракта == уб
Все так боятся этого страшного UB. Иногда хочется выписать профилактическую оплеуху очередному докладчику ругающему UB. Почему то все забывают что UB полезен, это отличный способ развязать руки опимизатору. Мы же не хотим при работе с массивом постоянно выполнять проверки выхода за массив, ведь это не бесплатная операция, вот UB и решает эту проблему.
В стандарте сейчас есть std::variant который не позволяет бесплатно получить содержимое, std::get и std::get_if выполняют проверку даже если автор кода точно знает что в нем храниться. Вот какой осел до этого додумался? В том же std::optional хватило мозгов сделать небезопасный оператор *.
При просмотре хотелось бы меньше смотреть на слушателей, а больше на экран.
Мне лично малоинтересно смотреть на лица других людей.
Проверка в рантайме это чушь, полная чушь. Даже рефлексию делают статической. Как же это плохо, у языка проблема с многословностью уже сейчас в одном объявлении функции можно увидеть template const constexpr static override delete noexcept nodiscard auto, а еще какую нибудь проверку SFINAE и вариадик параметры. Уже доходит до того, что объявление функции может быть в три раза объемнее реализации. Успокойтесь наконец, хватит. Как же я злюсь, в стандарте нет ни графики ни сетей, зато куча концептов да контрактов которые никак не реализуют
А как проверить рантаймовые значения не в рантайме?
@@bartolomeykant Писать обработчик. Дело в том что если требуется проверка значит нужна и корректная обработка, например бросить исключение или вернуть дефолтное значение. Если подразумевается что проверку обязуется выполнить вызывающая сторона, то глупо дублировать такие проверки. Проверки нарушения контрактов обычно выполняют упомянутым в видео assert. Если в коде нужно что-то более серьезное чем assert то на такой случай невозможно придумать стандарт, всегда будут уникальные запросы.
Возможно я не правильно понял суть, или автор видело не справился и не донес идею, но то что я увидел сильно разочаровывает.
Я был бы рад если бы продвигали в стандарт альтернативу макросу assert или механику позволяющую писать свои ассерты которые работали бы с модулями, но к сожалению в стандарт суют этот мусор, который отвлекает комитет от действительно важных задач.
В стандарте есть отличный инструмент static_assert пусть бы развивали его, например сейчас нет простого способа вывести имя типа в лог компилятора.
Обычные assert в бывают разбросанные по всему телу функции, это исключительно отладочный инструмент выполняющий роль встроенного юнит-теста, assert использует не только входные и выходные параметры а так же внутреннее состояние функции и даже глобальные данные, т.е. уже имеющийся инструмент горздо мощнее и гибче предлагаемых контрактов.
@@КошакРыжый по сути то что предлагается это asset до вызова функции, после вызова функции и можно еще несколько внутрь функции засунуть. И все это при срабатывании попадет в специальный обработчик, который один на все приложение. Для отладочных целей из этого обработчика можно напечатать стек трейс или дождаться подключения дебагерра. Больше он не зачем не нужен по сути. И этот механизм един во всем коде, какую бы стороннюю библиотеку вы не подключали. Получается вызов функции с контрактом исключает UB, так как нарушение контракта приводит к определенному поведению - крашу приложения. У меня ide мне подсказывает если я обращаюсь к значению optional без проверки, так и тут ide может предупреждать, что для вызова функции нужно сначала убедиться, что контракт соблюдается, а компилятор двойные проверки сможет оптимизировать.
Правильно нужно больше ключевых слов, а то компилятор пока не понимает нас на родном языке. Ну привели бы хоть статистику какую нибудь на сколько данный функционал востребован и кто им будет пользоваться. А то про мифические 100+ юз кейсы рассказали а кому этот функционал действительно нужен непонятно.
а с чего вы взяли что он кому-то нужен или что авторы делают его для кого-то?
кто угодно может написать свой пейпер и прийти с ним в комитет.
Вот люди захотели такое в C++ и они это делают.
Если хотите что-то еще - вперед.
Иначе слишком удобно сидеть на дивание ровно, ничего не предлагая, но критиковать людей которые прикладывают усилия чтобы что-то сделать.
@@feelamee язык программирования это не помойка куда каждый кому не лень может добавлять свои хотелки.
Язык должен быть минимально достаточным, лаконичным , легким в освоение конечно если вы хотите что бы он продолжал жить.
@@GrowHobbyRU я и не говорил что каждый может добавить в C++ что захочет) Я лишь сказал что каждый может попытаться.
Согласен с вашим видением языка, но для долгожителей вроде C++ это не работает. Тут всегда есть груз прошлого, который приходится тащить. Но люди стараются делать его проще и лаконичнее. По-моему - получается.
И контракты эта одна из полезных фич, которую я бы хотел видеть в C++. Не знаю в таком виде или нет.
Переводить технические определения с английского на русский это ужасно. Говорите по нормальному всегда на английском. Когда говорят на русском впечатление будто вы из села или в пту программирование учили
запретите русский язык, русскую культуру, россию наконец... маладец
Привыкнешь