Наверняка где-то простое добавление constexpr к сигнатуре функции невозможно в связи с текущей реализацией. Далее следует цепная реакция. В итоге придётся перелопатить чуть-ли не всё, что есть. Чем это лучше?
Что вы выберете, сделать эко-жигуль, впихнув в старый эко-двигатель или сделать нормальный и современный эко-мобиль и далее уже плясать вокруг него?
Или вам нравится, когда требования к тем же контейнерам выражаются письменно где-то здесь? Это хотя-бы концептами поправят…
ИМХО, проще тогда уже сделать новый язык, который по синтаксису, идеологии и каким-то основным приемам будет настолько сильно напоминать C++
Не соглашусь и уже далеко не одна подобная попытка была.
Стоит всё-таки разделить язык и его стандартную библиотеку.
Сам язык позволяет написать новую «идеальную» библиотеку, так что нет необходимости делать новый тысячный ЯП.
Все ключевые изменения 20-ого стандарта относятся строго к языку, а не к библиотеке, в том то и дело. И всё то, о чём я здесь так много писал, относиться только к библиотеке.
Вот я же не первый, кто пишет об «std2». Это периодически мелькает перед глазами: вот
и вот
и я искренне надеялся на то, что так и будет с C++20.
Вы ведь и сами желайте всё то, что есть модифицировать, но с учётом обратной совместимости вам это обходиться сложнее, чем могло быть. Мне кажется, что с 20-ым стандартом всё станет еще в пять раз сложнее.
Назревает новая эпоха, а библиотека Modern C++ всё еще не Modern.
Я не буду с вами спорить и я сам тремя руками за C++.
Просто в том споре мы знатно присели, оправдывая себя «обратной совместимостью» и возрастом.
Уж слишком убедительные и настырные противники были.
Но я вот совсем не планирую уходить на Rust, поскольку душа у меня к плюсам тянется.
Также я не требую «такие плюшки как в Rust». Я сейчас о другом говорил всё время. О том, что уже есть, но под новым углом.
Если мы сделаем std2, то как заставить пользователей на него быстро переехать? Если переезжать долго, то придётся десяток лет развивать две версии стандартной библиотеки, получать лучи ненависти от людей, вынужденных мигрировать на новую версию библиотеки…
Комитет ведь что-то сподвигло сделать C++ Core Guidelines и GSL.
И я подразумеваю то, что развитие старой библиотеки прекращается. Новая в себя будет включать идентичные сущности, но без мусора, в адекватном и чистом виде.
Я не настаиваю на том, что я абсолютно прав и нужно сделать так как я говорю) Не мне решать.
А главное — в чём плюсы то? Пока что, всё что хочется, все новые фишки, можно добавлять к стандартной библиотеке не меняя обратную совместимость.
Как по мне, «пока что» — это до C++20. Уж слишком масштабное обновление будет.
Согласитесь, что constexpr уже сместил сильно с места стандартную библиотеку, о чём я выше написал.
Я вижу библиотеку сейчас, как фундамент, который не был изначально рассчитан на тот груз, который на нём стоит. И со временем любое строение изнашивается и становиться более хрупким, тем-более если сверху достроить пару этажей и дополнительные балкончики, а также кондиционеры навешать)
О, я вас узнал сразу)
Но я же говорю не о безопасности, а обо всей библиотеке в целом. Да её можно сделать хоть смешав с GSL.
Факт в том, что на базе новых новшеств и базируясь на том, что язык за последние 20 лет тотально прокачался, нужно пересмотреть стандартную библиотеку вдоль и поперек. А старую оставить доживать ради обратной совместимости и всё.
Если сейчас посмотреть предложения на stdcpp.ru, то там большая часть предложений начинается со словосочетания «добавить constexpr к ...». Появляются модули, концепты и метаклассы. Это приведет к чему? К тому же самому, что происходит с constexpr. При этом модифицируя существующие сущности, которые уже много раз итак модифицировались и базировались совсем на других вещах, комитет получает головную боль, поскольку нужно все сделать аккуратно и нигде ничего не сломать и не переименовать и т.д. и т.п.
Также, что-то теряет свой смысл и со временем выбрасывается. Но это всё вытекает в то, что библиотека растянет на долгие годы (ибо стандарт выходит раз в 3 года) своё эволюционирование и в итоге придёт к тому же самому, что можно сделать здесь и сейчас и в разы проще.
Всё. Нужно позволить себе провести тотальный рефакторинг, с учётом появления супер-плюшек, появившихся за последние 16 лет и не бояться потерять обратную совместимость. Со спокойной душой пересмотреть большинство концепций и сделать библиотеку изначально заложив туда свежий фундамент, а не достраивать этажи поверх старого и не прочного фундамента.
Я понимаю, что я как-то сегодня прилично так умничаю, но просто мне кажется, что для молодых специалистов (как и я) был бы C++ более привлекателен с подобной новой и чистой библиотекой.
Недавно в теме по std::visit происходили серьёзные стычки между сообществом C++ и сообществом Rust. Аргументы Rust-овщиков были вполне убедительными, поскольку Rust — это молодой язык, который создавался опираясь на горький опыт своих предшественников.
А тут такой шанс по новому взглянуть на мир в пределах плюсов, с новыми возможностями и не заменять старую библиотеку и не приклеивать новые возможности к старым с помощью скотча, а сделать всё сразу и хорошо.
Ну ведь сейчас так и происходит, что все новые фичи прикручивают к старым. Тот же constexpr почти по всей библиотеке можно прилепить. Но это ведь в корне может поменять все концепции библиотеки.
Концепты, модули и метаклассы — это через чур глобальные изменения для того, чтобы быть использованными поверх старых наработок. Необходимо использовать сей потенциал. Иначе, всё-равно все станут писать свои велосипеды. Так и происходит сейчас даже. constexpr std::swap мне приходилось писать свой, абсолютно такой же, но с constexpr. Вы продвигаете constexpr std::regex. Контейнеров новые штуки также касаются. Итераторы будут безумно изящнее с концептами. Подобных примеров уже существует уйма. Библиотека std простаивает.
И всё-таки, насчёт библиотеки: constexpr(2011), концепты, метаклассы, модули. Чем не повод сделать абсолютно новую и чистую либу, которой будет легко и приятно пользоваться, которая не будет страдать от миллиона проблем?
Это всё мне напоминает чемодан, который с каждым годом становится всё дырявее и дырявее, а его выкинуть жалко, поэтому дырки латают и красят новым модным цветом.
Да все контейнеры (также их итераторы) и алгоритмы будут гораздо проще и выразительнее с концептами и с учётом существования compile-time выражений почти всё можно переписать и сделать чище.
При этом всём не нужно выкидывать старую библиотеку (дабы всеми необходимая обратная совместимость осталась). Но и развивать старую библиотеку я не вижу смысла.
Такой потенциал теряем…
да даже и не знаю. Возможно, какой-нибудь static_expr или compilet. Сходу так не скажешь. Но наличие восклицательного знака однозначно напрягает. В C++ нет ни одного ключевого слова с восклицательным знаком. Зачем нарушать эту тенденцию?
Ещё одно занятное изменение, которое рассматривается для приёма в C++20 — это constexpr! функции.
Я когда прочитал это предложение, то не понял в тот же миг, что оно говорит о чем-то новом)
constexpr!
Я вместо if(!result) пишу if (result == false), ибо восклицательный знак легко теряется из виду.
Может стоит дать другое имя?
И будут ли весь math модуль делать constexpr? Мне бы не помешал constexpr синус и косинус.
Да и может быть стоило бы всё-таки сделать какой-нибудь «std2»?
не знаю, что было, а чего не было, но помню, что я на собственном опыте проверял надёжность открытых сетей. Для начала сниффер проверил дома в своей сети, и зашёл в вк в чужой сеанс. Тогда в клиенте ВК на андроид безопасное соединение (https) было по-умолчанию выключено.
В универе так же я проверял работу сниффера и словил несколько сеансов OK и ВК. Зашёл через один сеанс на «Моя страница» и всё. Чужие данные я не стал изучать, ибо мне это не нужно было.
Я просто убедился в том, что открытые сети и соединение по http — не безопасно!
Даже ноут не обязательный. С андроид-устройства в универе как-то (в 2014-ом) заходил на чужие аккаунты сидящих в тот момент людей в ОК и ВК.
При этом для этого мне не потребовались какие-либо знания в этой области. Скачал сниффер, две кнопки тыкнул и все…
Я не «хакер» и даже в сети не разбираюсь
хорошо, что тут еще и не втянули std::weak_ptr, std::auto_ptr (который уже давно deprecated по понятным всем историческим причинам) и, конечно же, boost::intrusive_ptr (своеобразный shared_ptr).
Но всё же, во-первых, умные указатели являются не частью языка, а частью библиотеки C++. Появились они в недрах плюсовиков еще до появления Rust со своей пачкой умных указателей, на каждый случай и со стат. анализатором, как примесь к компилятору.
Но в плюсах то и голому указателю находиться применение. Например, мне не нужно атомарное копирование shared_ptr, мне не нужно перемещение указателя unique_ptr. Окей. На этот случай есть константная ссылка. Но, в тех же аллокаторах может понадобиться какая-нибудь адресная арифметика.
Плюс, назревает появление какого-то std::observer_ptr в копилку…
В Rust из коробки есть то, что появилось со временем в плюсах еще до появления Rust, только с блэкджеком. И что?
Этот весь бесполезный и не логичный спор напоминает мне противостояние винды(Rust) и Linux(C++).
Rust пока еще молодой язык, который не успел нагрешить и не несёт на себе тяжёлый груз обратной совместимости. И неизвестно еще чьи грехи будут страшнее.
github.com/fmtlib/fmt
en.cppreference.com/w/cpp/experimental/source_location
Пока есть только в gcc
Вам не кажется, что внедрение концептов, метаклассов, контрактов, constexpr-выражений в текущую библиотеку не станет более пагубным действием и слишком размазанным по следующему десятилетию?
Суть в том, что будет абсолютно свежий код, который станет более поворотливым.
Что предлагают сейчас:
constexpr std::regex
Переименовать все новые *_ref функции и классы в *_view
algorithm который можно использовать в constexpr
std::complex который можно использовать в constexpr
Убедить международный комитет не дублировать все контейнеры стандартной библиотеки
Constexpr для std::char_traits и std::string_view
constexpr для begin/end/reverse_iterator/move_iterator и базовых методов array
std::allocate_unique
Наверняка где-то простое добавление constexpr к сигнатуре функции невозможно в связи с текущей реализацией. Далее следует цепная реакция. В итоге придётся перелопатить чуть-ли не всё, что есть. Чем это лучше?
Что вы выберете, сделать эко-жигуль, впихнув в старый эко-двигатель или сделать нормальный и современный эко-мобиль и далее уже плясать вокруг него?
Или вам нравится, когда требования к тем же контейнерам выражаются письменно где-то здесь? Это хотя-бы концептами поправят…
Не соглашусь и уже далеко не одна подобная попытка была.
Стоит всё-таки разделить язык и его стандартную библиотеку.
Сам язык позволяет написать новую «идеальную» библиотеку, так что нет необходимости делать новый тысячный ЯП.
Все ключевые изменения 20-ого стандарта относятся строго к языку, а не к библиотеке, в том то и дело. И всё то, о чём я здесь так много писал, относиться только к библиотеке.
вот
и
вот
и я искренне надеялся на то, что так и будет с C++20.
Вы ведь и сами желайте всё то, что есть модифицировать, но с учётом обратной совместимости вам это обходиться сложнее, чем могло быть. Мне кажется, что с 20-ым стандартом всё станет еще в пять раз сложнее.
Назревает новая эпоха, а библиотека Modern C++ всё еще не Modern.
Просто в том споре мы знатно присели, оправдывая себя «обратной совместимостью» и возрастом.
Уж слишком убедительные и настырные противники были.
Но я вот совсем не планирую уходить на Rust, поскольку душа у меня к плюсам тянется.
Также я не требую «такие плюшки как в Rust». Я сейчас о другом говорил всё время. О том, что уже есть, но под новым углом.
Комитет ведь что-то сподвигло сделать C++ Core Guidelines и GSL.
И я подразумеваю то, что развитие старой библиотеки прекращается. Новая в себя будет включать идентичные сущности, но без мусора, в адекватном и чистом виде.
Я не настаиваю на том, что я абсолютно прав и нужно сделать так как я говорю) Не мне решать.
Как по мне, «пока что» — это до C++20. Уж слишком масштабное обновление будет.
Согласитесь, что constexpr уже сместил сильно с места стандартную библиотеку, о чём я выше написал.
Я вижу библиотеку сейчас, как фундамент, который не был изначально рассчитан на тот груз, который на нём стоит. И со временем любое строение изнашивается и становиться более хрупким, тем-более если сверху достроить пару этажей и дополнительные балкончики, а также кондиционеры навешать)
Там весь конфликт был не вокруг std::visit, а вокруг того, что Rust-овщики пришли прогонять C++ сообщество со своими правильными умными указателями)
Но я же говорю не о безопасности, а обо всей библиотеке в целом. Да её можно сделать хоть смешав с GSL.
Факт в том, что на базе новых новшеств и базируясь на том, что язык за последние 20 лет тотально прокачался, нужно пересмотреть стандартную библиотеку вдоль и поперек. А старую оставить доживать ради обратной совместимости и всё.
Если сейчас посмотреть предложения на stdcpp.ru, то там большая часть предложений начинается со словосочетания «добавить constexpr к ...». Появляются модули, концепты и метаклассы. Это приведет к чему? К тому же самому, что происходит с constexpr. При этом модифицируя существующие сущности, которые уже много раз итак модифицировались и базировались совсем на других вещах, комитет получает головную боль, поскольку нужно все сделать аккуратно и нигде ничего не сломать и не переименовать и т.д. и т.п.
Также, что-то теряет свой смысл и со временем выбрасывается. Но это всё вытекает в то, что библиотека растянет на долгие годы (ибо стандарт выходит раз в 3 года) своё эволюционирование и в итоге придёт к тому же самому, что можно сделать здесь и сейчас и в разы проще.
Я понимаю, что я как-то сегодня прилично так умничаю, но просто мне кажется, что для молодых специалистов (как и я) был бы C++ более привлекателен с подобной новой и чистой библиотекой.
Недавно в теме по std::visit происходили серьёзные стычки между сообществом C++ и сообществом Rust. Аргументы Rust-овщиков были вполне убедительными, поскольку Rust — это молодой язык, который создавался опираясь на горький опыт своих предшественников.
А тут такой шанс по новому взглянуть на мир в пределах плюсов, с новыми возможностями и не заменять старую библиотеку и не приклеивать новые возможности к старым с помощью скотча, а сделать всё сразу и хорошо.
Ну ведь сейчас так и происходит, что все новые фичи прикручивают к старым. Тот же constexpr почти по всей библиотеке можно прилепить. Но это ведь в корне может поменять все концепции библиотеки.
Концепты, модули и метаклассы — это через чур глобальные изменения для того, чтобы быть использованными поверх старых наработок. Необходимо использовать сей потенциал. Иначе, всё-равно все станут писать свои велосипеды. Так и происходит сейчас даже. constexpr std::swap мне приходилось писать свой, абсолютно такой же, но с constexpr. Вы продвигаете constexpr std::regex. Контейнеров новые штуки также касаются. Итераторы будут безумно изящнее с концептами. Подобных примеров уже существует уйма. Библиотека std простаивает.
Это всё мне напоминает чемодан, который с каждым годом становится всё дырявее и дырявее, а его выкинуть жалко, поэтому дырки латают и красят новым модным цветом.
Да все контейнеры (также их итераторы) и алгоритмы будут гораздо проще и выразительнее с концептами и с учётом существования compile-time выражений почти всё можно переписать и сделать чище.
При этом всём не нужно выкидывать старую библиотеку (дабы всеми необходимая обратная совместимость осталась). Но и развивать старую библиотеку я не вижу смысла.
Такой потенциал теряем…
Я когда прочитал это предложение, то не понял в тот же миг, что оно говорит о чем-то новом)
Я вместо if(!result) пишу if (result == false), ибо восклицательный знак легко теряется из виду.
Может стоит дать другое имя?
И будут ли весь math модуль делать constexpr? Мне бы не помешал constexpr синус и косинус.
Да и может быть стоило бы всё-таки сделать какой-нибудь «std2»?
В универе так же я проверял работу сниффера и словил несколько сеансов OK и ВК. Зашёл через один сеанс на «Моя страница» и всё. Чужие данные я не стал изучать, ибо мне это не нужно было.
Я просто убедился в том, что открытые сети и соединение по http — не безопасно!
При этом для этого мне не потребовались какие-либо знания в этой области. Скачал сниффер, две кнопки тыкнул и все…
Я не «хакер» и даже в сети не разбираюсь
Но всё же, во-первых, умные указатели являются не частью языка, а частью библиотеки C++. Появились они в недрах плюсовиков еще до появления Rust со своей пачкой умных указателей, на каждый случай и со стат. анализатором, как примесь к компилятору.
Но в плюсах то и голому указателю находиться применение. Например, мне не нужно атомарное копирование shared_ptr, мне не нужно перемещение указателя unique_ptr. Окей. На этот случай есть константная ссылка. Но, в тех же аллокаторах может понадобиться какая-нибудь адресная арифметика.
Плюс, назревает появление какого-то std::observer_ptr в копилку…
В Rust из коробки есть то, что появилось со временем в плюсах еще до появления Rust, только с блэкджеком. И что?
Этот весь бесполезный и не логичный спор напоминает мне противостояние винды(Rust) и Linux(C++).
Rust пока еще молодой язык, который не успел нагрешить и не несёт на себе тяжёлый груз обратной совместимости. И неизвестно еще чьи грехи будут страшнее.