Комитет должен отойти от практики публикации опережающих реальность спецификаций. Вместо того, чтобы декларировать свои фантазии …
Мне кажется, что в С++26 включили рефлексию и контракты, просто чтобы снизить градус критики комитета. Как будто подкинули пару задач на ближайшие три года, чтобы не заниматься безопасностью и действительно важными вещами.
Я не хочу сказать, что рефлексию и контракты вещи “не важные”. Важные, вот только статическая рефлексия типов в текущем виде напрашивалась пару десятилетий назад, а контракты предложены в кокой-то непонятной (для меня) форме.
Было бы понятно, если бы контракты были аналогичны реализованным в Ада как элемент доказательно программирования во время компиляции для сужения значений у типов данных. Но если я правильно понял, принятый в С++26 вариант контрактов не вводит сужения значений для типов, а реализует обычные проверки условий, в том числе и в рантайм, что делает их обычной комбинацией static_assert и обычного assert. И стоило из-за этого городить огород?
На мой взгляд, одна из ключевых и пока что нерешенных проблем C++ в том, что в огромном количестве проектов исключения под запретом. Да, идея была крутой для конца 1980-х, однако испытания реальностью не выдержала.
Мне кажется, что исключения так и остаются самой крутой штукой С++ и выдержали испытания, так как их функционал присутствует во всех языках программирования, даже тех, кто от них якобы отказалася.
Но сложности с их использования действительно есть, но как правило это не проблема С++ как такового, а проблема интерфейса между компонентами, ведь extern “C” ничего не знает об исключениях. Поэтому не помешал бы какой нибудь дополнительный механизм их проброса исключений через интерфейсы.
Типа в начале .cpp-файла указывается версия С++, для которой в этом файле пишется код. Но, к сожалению, эту идею в комитете похоронили.
Идея привязки кода к разным версиям стандарта существует до сих пор и частично прорабатывается в профилях безопасности. Просто это привязка реализуется не к нумерации стандарта С++, а к его возможностям, которые не связанных одной версией, что гораздо более правильно, как мне кажется.
то, что есть в тех компиляторах, которыми приходится пользоваться. Собственно, это и есть реальный С++. …
На самом деле скорее всего есть четыре, а не три типа С++. Четвертый вид С++идет идет следующим и называется “то, что реально пользуются в продакшене”. Обычно это возможности, которые отстают от третьего пункта на несколько поколений стандарта. Возможности, у кого известны все подводные камни и нюансы и есть наработана легаси практика.
А, нет. Есть еще и пяты тип С++ - это весь объем легаси кода, который тянет за собой обязательное требование по обратной совместимости со самыми старыми версиями и именно этоот пятый вид и тормозит развитие С++.
Он позволил реализовать полную рефлексию в ROOT (я один из соавторов). Одно условие, все классы наследовались от TObject.
Статическая рефлексия и рефлексия в рантайм, это не одно и тоже. И если речь идет о рефлексии в рантайме, то совершено правильно, что Страустрап на это не пошел.
Герб Саттер когда-то анонсировал свой cpp2, который превратился в C++26, в котором Будет Усе… и reflection и memory safety.
Проблема не в самой нулевой ссылке, а в том, что языки её не проверяют. В С/С++, проблема не в самом null, а в том, что ссылка может быть не инициализирована и иметь произвольное значение, т.е. проблема как раз в том, что она НЕ является нулевой :-)
Вы зря меня считаете пессимситом, я скорее реалист, так как это изначальное предложение по рефлексии было близким к полной, но потом её ужали только до рефлексии типов, чтобы хоть с чего-то начать. Это тоже очень хорошо, так как с помощью C++26 можно закрыть некоторые проблемы.
Про отдельный форк clang с реализацией рефлексии я знаю, но так не сумел его протестить самостоятельно. Решил дождаться официального анонса хоть в каком нибудь виде.
К сожалению “базовая”, это только на уровне типов. Часть проблема это снимает, вроде той же сериализации, но рефлексию для тела функции или хотя бы блоков кода наверно не будет вообще никогда.
Макросы и инклуды в модулях решались чуть ли не десять лет, и когда этот процесс завершиться пока еще непонятно.
Метапрограммирование лучше вообще не комментировать. Да, концепты улучшили ситуацию, хоть они и обсуждались с 2000-х годов, но в результате SFINAE все равно приходится тащить, так как обратная совместимость :-(
Сложность многопоточки решается больше уже поддержкой сообщества с появлением более удобных библиотек.
Так это потому, что нет других вариантов. Если бы была рефлексия не для типов, а хотя бы на уровне фрагментов AST, можно было бы реализовать часть проверок во время компиляции.
А раз ничего этого нет и не ожидается, вот и приходится городить огород с помощью библиотек. Но это ограничения на уровне договоренностей или ревью кода, т.е. “на счетном слове”, а не на уровне стандарта языка :-(
Автор считает, что нужен трансплитеор не в С, а именно в С++ как раз для того, чтобы была возможность реализовать обратную совместимость с С++ в каком угодно объеме.
Изъяны С++ вытекают из его семантики и стандартов, тогда как для обеспечения низкоуровневой обратной совместимости достаточно реализовать компилятор языка как трансплайтер в С++.
Пример Rust - это демонстрация невозможности его применения как прямой замены С++ и использование только в нишевых областях или отдельных проектах без легаси кода.
Тогда как для замены С++ - обеспечение обратной совместимости - это обязательное, хоть и не достаточное условие согласно банальным экономическим соображениям.
А кто вам мешает именно в этом месте сделать другой способ обработки ошибок, например на возвращаемых значениях?
Мне кажется, что в С++26 включили рефлексию и контракты, просто чтобы снизить градус критики комитета. Как будто подкинули пару задач на ближайшие три года, чтобы не заниматься безопасностью и действительно важными вещами.
Я не хочу сказать, что рефлексию и контракты вещи “не важные”. Важные, вот только статическая рефлексия типов в текущем виде напрашивалась пару десятилетий назад, а контракты предложены в кокой-то непонятной (для меня) форме.
Было бы понятно, если бы контракты были аналогичны реализованным в Ада как элемент доказательно программирования во время компиляции для сужения значений у типов данных. Но если я правильно понял, принятый в С++26 вариант контрактов не вводит сужения значений для типов, а реализует обычные проверки условий, в том числе и в рантайм, что делает их обычной комбинацией static_assert и обычного assert. И стоило из-за этого городить огород?
Мне кажется, что исключения так и остаются самой крутой штукой С++ и выдержали испытания, так как их функционал присутствует во всех языках программирования, даже тех, кто от них якобы отказалася.
Но сложности с их использования действительно есть, но как правило это не проблема С++ как такового, а проблема интерфейса между компонентами, ведь extern “C” ничего не знает об исключениях. Поэтому не помешал бы какой нибудь дополнительный механизм их проброса исключений через интерфейсы.
Идея привязки кода к разным версиям стандарта существует до сих пор и частично прорабатывается в профилях безопасности. Просто это привязка реализуется не к нумерации стандарта С++, а к его возможностям, которые не связанных одной версией, что гораздо более правильно, как мне кажется.
На самом деле скорее всего есть четыре, а не три типа С++. Четвертый вид С++идет идет следующим и называется “то, что реально пользуются в продакшене”. Обычно это возможности, которые отстают от третьего пункта на несколько поколений стандарта. Возможности, у кого известны все подводные камни и нюансы и есть наработана легаси практика.
А, нет. Есть еще и пяты тип С++ - это весь объем легаси кода, который тянет за собой обязательное требование по обратной совместимости со самыми старыми версиями и именно этоот пятый вид и тормозит развитие С++.
Рефлексия может быть в рантайм (получить информацию о классе во время выполнения программы) и может быть статическая, т.е. только во время компиляции.
В С++ рефлексия статическая без рантайм оверхеда, который неизбежен в случае наследования всех классов от TObject.
Статическая рефлексия и рефлексия в рантайм, это не одно и тоже. И если речь идет о рефлексии в рантайме, то совершено правильно, что Страустрап на это не пошел.
Герб Саттер не позиционировал свой проект, как замена С++, тем более с reflection и memory safety. In short, it aims to help evolve C++ itself, not to be a “C++ successor.”.
Так это проблема, что программист не проверяет указатель на недействительность, а не самого nullptr.
Можно принудительно кастануть Option, когда там нет инициализировнного указателя и тоже будет ошибка, но ведь это не становится проблемой Option?
Убирать что, nullptr или возможность создавать не инициализированные указатели?
Ну ведь это ученый изнасиловал журналиста.
Проблема не в самой нулевой ссылке, а в том, что языки её не проверяют. В С/С++, проблема не в самом null, а в том, что ссылка может быть не инициализирована и иметь произвольное значение, т.е. проблема как раз в том, что она НЕ является нулевой :-)
Вы зря меня считаете пессимситом, я скорее реалист, так как это изначальное предложение по рефлексии было близким к полной, но потом её ужали только до рефлексии типов, чтобы хоть с чего-то начать. Это тоже очень хорошо, так как с помощью C++26 можно закрыть некоторые проблемы.
Про отдельный форк clang с реализацией рефлексии я знаю, но так не сумел его протестить самостоятельно. Решил дождаться официального анонса хоть в каком нибудь виде.
К сожалению “базовая”, это только на уровне типов. Часть проблема это снимает, вроде той же сериализации, но рефлексию для тела функции или хотя бы блоков кода наверно не будет вообще никогда.
Макросы и инклуды в модулях решались чуть ли не десять лет, и когда этот процесс завершиться пока еще непонятно.
Метапрограммирование лучше вообще не комментировать. Да, концепты улучшили ситуацию, хоть они и обсуждались с 2000-х годов, но в результате SFINAE все равно приходится тащить, так как обратная совместимость :-(
Так это потому, что нет других вариантов. Если бы была рефлексия не для типов, а хотя бы на уровне фрагментов AST, можно было бы реализовать часть проверок во время компиляции.
А раз ничего этого нет и не ожидается, вот и приходится городить огород с помощью библиотек. Но это ограничения на уровне договоренностей или ревью кода, т.е. “на счетном слове”, а не на уровне стандарта языка :-(
К сожалению, только базовая и только в виде требований, пока без поддержки в компиляторах
Автор считает, что нужен трансплитеор не в С, а именно в С++ как раз для того, чтобы была возможность реализовать обратную совместимость с С++ в каком угодно объеме.
Сделал опрос для статьи, чтобы была конкретика для обсуждения
Изъяны С++ вытекают из его семантики и стандартов, тогда как для обеспечения низкоуровневой обратной совместимости достаточно реализовать компилятор языка как трансплайтер в С++.
Пример Rust - это демонстрация невозможности его применения как прямой замены С++ и использование только в нишевых областях или отдельных проектах без легаси кода.
Тогда как для замены С++ - обеспечение обратной совместимости - это обязательное, хоть и не достаточное условие согласно банальным экономическим соображениям.
Обратная совместимость с миллиардами строк кода, написанными за последние 30-40 лет, это не обязательное условие? Ну-ну…
Ну так это обязательно, но не достаточно условие
Чтобы быть честным, решил опубликовать и статью-контраргумент Ахиллесова пята C++ и будущая р̶е̶ эволюция, почему C++ всё равно будет рано или поздно заменён.