какой смысл, если статья описывает то, что уже отлито в граните?
Ну, во первых, ещё не отлито. Во вторых, рефлексия уже лет 7 варится, времени повлиять у заинтресованных людей было предостаточно. В третьих, мало того что целая прорва постов была во множестве соц сетей, так и несколько рабочих прототипов на godbolt.
За эти годы рефлексия активно менялась под фидбеком пользователей. И менялись важные фундаментальные части: ушли от шаблонов к type erased meta::info, репортить ошибки стали через исключения и т.д.
И если самая большая проблема рефлексии, это необходимость использовать :вместо предпочитаемого вами@ - то всё сделано комитетом просто замечательно.
Но по факту решение принято за почти закрытыми дверьми, повлиять на него, кроме как участвуюя в работе комитета, у таких как я, нет возможности.
Вот именно! У вас есть возможность повлиять на результат. Но ведь высказывать "фи" намного проще, чем прорабатывать и продумывать идеи
у меня есть сомнения в том, что у комитета сейчас есть нормальная обратная связь с пользователями
Обратной связи много, но дельных мыслей и рабочих идей - крайне мало. Как правило связь вида "не программирую, но осуждаю" или "ну наконец, отлично!", или "мне не нравится синтаксис, вот вам другой сомнительный синтаксис".
Вот например у статьи уже набралось почти пол сотни комментариев. Есть ли средини них хоть пара, с которыми можно работать?
Ваше предложение по ссылке не позволяет получить информацию о том, позвали && функцию или const& функцию. Соответсвенно вы потеряли огромный кусок функционала, получив синтаксис не лучше чем с deducing this
Всё именно так. Изначальгное предложение было с for constexpr, но в core группе посоветовали переделать на template, т.к. это лучше отражает происходящее под капотом
Над profiles активно идёт работа, Герб Саттер её возглавил. На прошлом заседании комитета профили были соверешенно не готовы (не было ни реализации, ни приблизительного понимания как они должны работать на большой кодовой базе)
Есть очень небольшой шанс, что получится работу над ними выпустить отдельным стандартом, сразу после C++26
Эти функции из N3815 не позволяют кодогенерировать, и обладают рядом других проблем...
Но основная идея - зачем стандартизировать часть функций, если все равно даже малой части потребностей разработчиков ими не закрыть. Можно же вместо этого предоставить механизм (рефлексию), чтобы разработчики могли создавать любые свои функции самостоятельно
Это обычная ситуация для всех языков программирования, которые активно развиваются. Вон даже в простом C сравнительно недавно напортачили с extern inline.
Просто зачастую у нас есть язык, за которым внимательно следим, и не очень замечаем что в других проблемы не меньше.
Прототипы рефлексии есть для clang, и кажется что для GCC тоже. Так что надеюсь, что реализуют сравнительно быстро, тем более что изменения затрагивают только frontend компилятора (в отличие от модулей, которые затрагивают вообще всё, включая системы сборки)
Интерес огромный, а вот с возможностями compile time вычислений в 2007 было очень тяжко. В C++11 constexpr функция должна была состоять только из одного return, в C++14 уже можно было делать циклы... А потом уже появились динамические аллокации в constepr, исключения, стандартная библиотека подтянулась
Не могу сказать за другие языки программирования, но качество C++ ПО ощутимо улучшается. Появились санитайзеры, выработалась культура по обязательному написанию тестов и использованию CI, компиляторы обзавелись внушительным количеством встроенной диагностики, меньше людей пишет в стиле "C++ с классами" (в институтах начали нормально рассказывать про RAII!), всё меньше проектов с самописными и забагованными версиями variant|string|optional. Да даже если судить по одним только Хабру и чатику pro.cxx, уровень квалификации очень ощутимо вырос за последние 15 лет.
Я тоже горю идеей destructive move, но со временем она кажется всё менее и менее привлекательной. Современные компиляторы очень неплохо убирают мертвый код деструкторов вида `~Foo() { if (not_moved) delete not_moved; }`. Современный LTO тоже весьма неплохо помогает компилятору в более сложных случаях move+destroy
Если идею доработают до разумного состояния (последние предложения ломали приложения на ряде платформ и очень усложняли язык) - будет маленький праздник.
Ну, во первых, ещё не отлито. Во вторых, рефлексия уже лет 7 варится, времени повлиять у заинтресованных людей было предостаточно. В третьих, мало того что целая прорва постов была во множестве соц сетей, так и несколько рабочих прототипов на godbolt.
За эти годы рефлексия активно менялась под фидбеком пользователей. И менялись важные фундаментальные части: ушли от шаблонов к type erased meta::info, репортить ошибки стали через исключения и т.д.
И если самая большая проблема рефлексии, это необходимость использовать
:вместо предпочитаемого вами@- то всё сделано комитетом просто замечательно.Вот именно! У вас есть возможность повлиять на результат. Но ведь высказывать "фи" намного проще, чем прорабатывать и продумывать идеи
Обратной связи много, но дельных мыслей и рабочих идей - крайне мало. Как правило связь вида "не программирую, но осуждаю" или "ну наконец, отлично!", или "мне не нравится синтаксис, вот вам другой сомнительный синтаксис".
Вот например у статьи уже набралось почти пол сотни комментариев. Есть ли средини них хоть пара, с которыми можно работать?
Ваше предложение по ссылке не позволяет получить информацию о том, позвали
&&функцию илиconst&функцию. Соответсвенно вы потеряли огромный кусок функционала, получив синтаксис не лучше чем с deducing thisА с deducing this что не так?
Ну тут дело вкуса... Мне вот
@наоборот не нравится.[^^ что-то ^^]использовать не стоит, оно вызывает сложности парсинга, т.к. ^^ уже отдельный оператор.Текущий синтаксис - результат множества голосований. Это тот синтаксис, который однозначен и устраивает большинство людей в комитете
Можете пожалуйста детальнее расписать, что именно не так и как сделать правильнее?
Всё именно так. Изначальгное предложение было с for constexpr, но в core группе посоветовали переделать на template, т.к. это лучше отражает происходящее под капотом
А что по вашему в данной рефлексии не так?
Над profiles активно идёт работа, Герб Саттер её возглавил. На прошлом заседании комитета профили были соверешенно не готовы (не было ни реализации, ни приблизительного понимания как они должны работать на большой кодовой базе)
Есть очень небольшой шанс, что получится работу над ними выпустить отдельным стандартом, сразу после C++26
Да, в Болгарии
P.S.: Напишите пожалуйста в личку, какая ссылка не работает
Эти функции из N3815 не позволяют кодогенерировать, и обладают рядом других проблем...
Но основная идея - зачем стандартизировать часть функций, если все равно даже малой части потребностей разработчиков ими не закрыть. Можно же вместо этого предоставить механизм (рефлексию), чтобы разработчики могли создавать любые свои функции самостоятельно
Это обычная ситуация для всех языков программирования, которые активно развиваются. Вон даже в простом C сравнительно недавно напортачили с extern inline.
Просто зачастую у нас есть язык, за которым внимательно следим, и не очень замечаем что в других проблемы не меньше.
Прототипы рефлексии есть для clang, и кажется что для GCC тоже. Так что надеюсь, что реализуют сравнительно быстро, тем более что изменения затрагивают только frontend компилятора (в отличие от модулей, которые затрагивают вообще всё, включая системы сборки)
Всё работает как ожидается. break перепрыгивает за конец цикла, continue перепрыгивает к началу на проверку условий
Интерес огромный, а вот с возможностями compile time вычислений в 2007 было очень тяжко. В C++11 constexpr функция должна была состоять только из одного return, в C++14 уже можно было делать циклы... А потом уже появились динамические аллокации в constepr, исключения, стандартная библиотека подтянулась
С шаблонными методами и параметрами работа поддержана, получить список функций можно через members_of. Так что кажется что можно все :)
Боль по сравнению со специально написаным человекочитаемым static_assert в котором указано как исправить проблему.
Если сравнивать с альтернативой в виде std::enable_if, то концепты лучше.
Не могу сказать за другие языки программирования, но качество C++ ПО ощутимо улучшается. Появились санитайзеры, выработалась культура по обязательному написанию тестов и использованию CI, компиляторы обзавелись внушительным количеством встроенной диагностики, меньше людей пишет в стиле "C++ с классами" (в институтах начали нормально рассказывать про RAII!), всё меньше проектов с самописными и забагованными версиями variant|string|optional. Да даже если судить по одним только Хабру и чатику pro.cxx, уровень квалификации очень ощутимо вырос за последние 15 лет.
С Boost.Regex остаётся проблема, что он позволяет backtracking, а соответсвенно уязвим к ReDOS атакам :(
Рекомендую использовать Re2
P.S.: у меня в команде хотели написать статью на эту тему. Было бы вам интересно почитать?
Я тоже горю идеей destructive move, но со временем она кажется всё менее и менее привлекательной. Современные компиляторы очень неплохо убирают мертвый код деструкторов вида `~Foo() { if (not_moved) delete not_moved; }`. Современный LTO тоже весьма неплохо помогает компилятору в более сложных случаях move+destroy
Если идею доработают до разумного состояния (последние предложения ломали приложения на ряде платформ и очень усложняли язык) - будет маленький праздник.