Опубликованы C++ Core Guidelines

Я выше привел цитату Саттера со словами «I did design» - очевидно, он считает, что раньше лайфтаймов не было

По той цитате вообще не очевидно, что она относится к каким-либо lifetime.

А насчет RAII - если использовать термин lifetime так свободно, то lifetime-ы появились еще в Algol 68 или там BCPL.

Вот именно, так что любителям Rust-а нужно как-то доказать, что Rust начал оказывать влияние на C++.

Только вот это суждение было озвучено только несколько лет назад.

Это суждение было озвучено Страуструпом давным-давно, в 90-х - ещё до выхода первого стандарта языка. Послушай его уже наконец. https://www.youtube.com/watch?v=1OEu9C51K2A&t=3m47s

Так что нет.

Типа, привел цитату про стандартную библиотеку из стандарта языка, и продолжаешь утверждать, что она к языку не относится? Ну ОК. Это уже словоблудие и переливание из пустого в порожнее.

А насчет RAII - если использовать термин lifetime так свободно, то lifetime-ы появились еще в Algol 68 или там BCPL.

Вот именно, так что любителям Rust-а нужно как-то доказать, что Rust начал оказывать влияние на C++.

Зачем? Даже ozkriff сказал всего лишь «правильность и перспективность подхода ржавчины». Ни про влияние Rust на Си++, ни про уникальность подхода Rust не говорится.

Впрочем, ссылка на встречу Саттера с разрабами Rust тоже была приведена - есть нехилые шансы, что Rust окажет влияние на Си++.

Только вот это суждение было озвучено только несколько лет назад.

Это суждение было озвучено Страуструпом давным-давно, в 90-х - ещё до выхода первого стандарта языка

Даже если верить ему (а учитывая упоминание «safe», верится с трудом), он приписывает ее 1992-1994 - когда Си++ уже развивался ~10 лет и количество изменений в нем уже было больше, чем за всё время жизни Си.

Типа, привел цитату про стандартную библиотеку из стандарта языка

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

Даже ozkriff сказал всего лишь «правильность и перспективность подхода ржавчины».

ozkriff пока ничем не подтвердил свои слова. Ты, кстати говоря, тоже :)

Даже ozkriff сказал всего лишь «правильность и перспективность подхода ржавчины».

ozkriff пока ничем не подтвердил свои слова. Ты, кстати говоря, тоже :)

Ты просто отказываешься считать это подтверждениями. Наверное, тебе нужна нотариально заверенная подпись Саттера под документом «Раньше лайфтаймов в Си++ не было и Rust послужил моделью для их добавления».

А аннотации лайфтаймов в Си++ реально корявые: [[lifetime(thing)]]. Но всегда найдутся люди, которые будут вонять о синтаксисе Rust :/

Наверное, тебе нужна нотариально заверенная подпись Саттера под документом «Раньше лайфтаймов в Си++ не было и Rust послужил моделью для их добавления».

Это, как минимум, сняло бы все вопросы.

Если при наличии документа за авторством Саттера, в котором описываются проверки лайфтаймов и синтаксис их аннотаций, и запланированной встреча с Rust core team тебе нужна еще и заверенная подпись... ну окей.

Если при наличии документа за авторством Саттера, в котором описываются проверки лайфтаймов и синтаксис их аннотаций

Документ я пока еще не прочел, вернемся к данному вопросу позже.

Я вот не вижу никаких проблем во влиянии одних языков на другие. Ну пусть что-то полезное где-то реализовали раньше, что с того? Если это можно органично вписать в C++, то это же замечательно. Проблема возникает как раз тогда, когда язык невозможно органично изменить. И что-то мне подсказывает, что эта проблема гораздо более характерна для Rust. Наверное, недавний спор про сопрограммы в Rust меня на эту мысль наводит.

Чуваки, добавьте статично проверяемые лайфтаймы и паттерн-матчинг - и фиг с ним, с Rust'ом.

есть нехилые шансы, что Rust окажет влияние на Си++

Разумеется, разрабам Rust невыгодно что-то правильно объяснять Саттеру. Ему навешают лапши - и всё, C++-капец :D

... Rust послужил моделью для их добавления.

Так, вот этого я не говорил) Ты же сам копипастил сюда цитату, где он мамой клянется, что в глаза ржавчину не видел, пока не закончил работу над своим видением «безопасных» плюсов.

Чуваки, добавьте статично проверяемые лайфтаймы и паттерн-матчинг - и фиг с ним, с Rust'ом.

А почему только это добавить?

Так, вот этого я не говорил

Но я и не приписывал тебе этих слов.

А аннотации лайфтаймов в Си++ реально корявые: [[lifetime(thing)]].

Это синтаксис атрибутов. В rust оно пишется #[attribute(value)]. Т.е. почти так само.

Но всегда найдутся люди, которые будут вонять о синтаксисе Rust :/

Ты же сам только что и обосрал практически синтаксис Rust.

Я в любом случае не понял, почему ты это написал)

А аннотации лайфтаймов в Си++ реально корявые: [[lifetime(thing)]].

Это синтаксис атрибутов.

[[lifetime(thing)]] - это аннотация лайфтайма. И она гораздо ублюдочнее растовского 'a.

Ты же сам только что и обосрал практически синтаксис Rust.

Ты бредишь.

[[lifetime(thing)]] - это аннотация лайфтайма

В С++ нет аннотации лайфтайма. А атрибуты с таким синтаксисом есть. Хотя в твоем волшебном мире эльфов может и по другому.

И она гораздо ублюдочнее растовского 'a.

Нет, растовский ' превращает строку в перловку. Кроме того ты сравниваешь синтаксис атрибутов с отдельным синтаксисом под lifetime. Хоть ты и отказываешься это понимать.

Ты бредишь.

Это ты что-то не то покурил и тебя опять понесло сравнивать свои фантазии с реальностью.

Чуваки, добавьте статично проверяемые лайфтаймы и паттерн-матчинг - и фиг с ним, с Rust'ом.

А почему только это добавить?

А что еще в ржавчине существенного? Модули и концепты, считай, одной ногой в плюсах. Про пакетный менеджер разговоры активизировались. Еще бы разрешили иногда опускать auto:

const x = 42;
foo() -> int;

- и синтаксис был бы чуть менее корявый.

Что еще есть интересного? Я раст мало знаю, есличо.

Если это можно органично вписать в C++, то это же замечательно.

Да в плюсы что угодно можно вписать «органично», они уже любое издевательство могут стерпеть))

И что-то мне подсказывает, что эта проблема гораздо более характерна для Rust. Наверное, недавний спор про сопрограммы в Rust меня на эту мысль наводит.

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

А можно поподробней про спор и мысли?

Если при наличии документа за авторством Саттера, в котором описываются проверки лайфтаймов и синтаксис их аннотаций, и запланированной встреча с Rust core team тебе нужна еще и заверенная подпись... ну окей.

Просмотрел этот документ за авторством Саттера. В нем слишком много формализма для меня, подобный документ интересен для разработчиков компиляторов и статических анализаторов.

Тем не менее, какого-то влияния Rust-а на предложения Саттера не видно. Добавляем сюда твою же цитату о том, что Саттер не смотрел на Rust в процессе подготовки предложений. Добавляем сюда то, что Саттер планирует встречу с Rust core team уже после публикации свои предложений... И получаем, что влияние Rust-а на людей из C++ного комитета несколько преувеличено.

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

[[lifetime(thing)]] - это аннотация лайфтайма

В С++ нет аннотации лайфтайма

Будет. Можешь спросить Саттера.

какого-то влияния Rust-а на предложения Саттера не видно

Никто и не говорил, что оно есть. Я говорю, что оно может быть в будущем (а может и не быть, если он достаточно твердолоб).

декларации лайфтаймов, над которыми ты поржал

Я над ними поплакал.

Их нужно писать не везде, в отличии от

В отличие от чего - Cyclone? Потому что в Rust их тоже нужно писать не везде.

ozkriff пока ничем не подтвердил свои слова.

А? Я не говорю, что ржавчина оказала влияние на эту работу Саттера. Я просто говорю, что предложенное Саттером сильно напоминает ржавчину. Отличий много, но направление мысли схожее. И это, как по мне, говорит о признаии Саттером и сочувствующими правильности и перспективности этого направления мысли. Все, собственно)

Вообще, я тоже по-диагонали прочитал все это дело, а детальное ознакомление отложил до момента, когда можно будет запустить и пощупать их анализатор.

Будет. Можешь спросить Саттера.

Ну как будет - тогда и приходи.

Я бы хотел просто узнать, на чем базируется вот это утверждение:

А с другой стороны главные плюсоводы признают правильность и перспективность подхода ржавчины.

Где плюсоводы признают правильность?

Я просто говорю, что предложенное Саттером сильно напоминает ржавчину. Отличий много, но направление мысли схожее. И это, как по мне, говорит о признании Саттером и сочувствующими правильности и перспективности этого направления мысли. Все, собственно)

На си можно писать код. Красиво, улыбаясь так писать и наслаждаться. Код будет работать быстро. На плюсах можно рисовать закарючки богу закорючек, делать 100500 конструкторов и копи и мув конструкторов, а еще 2-3 деструктора с исключениями, потом перечитать стауструпа глав так 20 чтобы вспомнить как оно там все должно быть и не забыть таблицу виртуальных функций составить. Когда все сделал, надо еще переопределить оператор скобочка. Это чтоб никто не догадался, что именно ты понимаешь, когда пишешь скобочку. Тоже самое лучше сделать с '=', желательно в каждом классе. Потом можно выдохнуть, посмотреть на часы и не уходит домой, потому что 5 утра.

Вот! Берите пример, как человека бомбануло.

а как в расте идеоматично делать заглушку типа pass в питоне? Типа такого:

match qwe() {
  Ok(_) => pass,
  Err(e) => log(e)
}

как в расте идеоматично делать заглушку типа pass в питоне?

match qwe() {
  Ok(_) => {},
  Err(e) => log(e)
}

или

match qwe() {
  Ok(_) => (),
  Err(e) => log(e)
}

обычно.

А для данного конкретного кода, раз тебе ветка с Ok вообще не нужна, можно

if let Err(e) = qwe() {
  log(e)
}

Спасибо!

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

Ну так уж и «одной ногой». Сколько еще лет пройдет.

Про пакетный менеджер разговоры активизировались.

Да? Можно поподробней?

А что еще в ржавчине существенного?

Существенного? Это ж индивидуально. Какой-нибудь убежденный функциональщик-пурист вполне может сказать что ржавчина ничем от плюсов не отличается.

Да и важен не просто набор «фичей», важно еще чего в языке нет и как все это сочетается одно с другим. Язык это система.

Можешь вот тут, например, почитать чего разные растоводы считают важным.

Концепты уже одобрены и реализованы в экспериментальной ветке gcc, так что будут в 17-м, или когда там выйдет стандарт :D

Модули тоже хотят успеть, хотя бы в виде TS. Реализация уже есть.

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

Да, rust более аккуратный и чоткий. Синтаксис нормальный, хотя читаемость всё равно под вопросом. Ну, может, дело привычки. Это, к сожалению, в плюсы не «добавить».

Почитал бегло реддит - увидел еще две фичи: параллелизм и юникод. Это надо плотнее смотреть, чтобы выводы делать.

Концепты уже одобрены и реализованы в экспериментальной ветке gcc, так что будут в 17-м, или когда там выйдет стандарт :D

Ага. Они и в 11 должны были войти, но потом их выкинули как незрелые.

За обновленные концепты вроде как летом проголосовали.

Это, к сожалению, в плюсы не «добавить».

Я о том и говорю, что ржавчина не станет бесполезна, даже если вытянуть в плюсы что получится. Есть и другие вещи, кроме тупо синтаксиса, которые в плюсы уже просто так не добавить. Иммутабельность/приватность по умолчанию и явные unsafe{} блоки, например. Мне, как растолюбу, кажется что дело не просто в количестве фич)

юникод

Про то, насколько поддержка юникода является фишкой ржавчины - хз. Я, вроде, и в плюсах с юникодом не страдаю особенно как-то.

параллелизм

Это же часть пункта «лайфтаймы», как по мне. Я под этим имел ввиду всю работу с памятью - не просто зависимость ссылок от времени жизни других ссылок/объектов и возможность дать этому дело явные имена, а еще и невозможность просто так иметь больше одной мутабельной ссылки на одну сущность. Плюс отсутствие null, простая семантика перемещения и запрет на изменяемые глобальные переменные, тоже приятно.

Работа с памятью в сочетании с явным unsafe{} - самый жирный пункт, как по мне. Из «мелочей» в голову еще приходят обычные и процедурные макросы и адт, например.

Еще rustfmt должны бы уже скоро допилить, срачи про форматирование должны скукожиться.

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

Ну так ломают, да.

я пока не очень разобирался, на что этот новый плюсовый внешний анализатор будет ругаться в плане устаревшего кода.

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

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

Заметка же не про предел сложности, а про бюджет странности (или количество инноваций), очевидно ;) То есть про то, как добиться, чтобы люди, которые уже что-то знают, использовали этот новый язык:

getting people to use it is much, much harder. If your aim is to build a practical programming language with a large community, you need to be aware of how many new, interesting, exciting things that your language is doing, and carefully consider the number of such features you include.

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

Далее, что касается зоопарка исследовательских языков для языковедов, то я не против этого зоопарка. Мне не нравится зоопарк в мейнстриме, где, как правильно замечено в комменте

The current batch of mainstream programming languages are all clustered around a couple of very small local minima in the total design space. For example javascript, python, ruby, etc are all very similar, as are things like Java, C#, Go or C++, D, Ada, etc. Sure they make a few tweaks here and there, but if you squint they're quite similar.

Я не специалист по расту, но всё, что я о нем знаю, говорит о том, что он из этой же компании. Ибо главная его фишка —

A great example of bringing new research into the mainstream is actually Rust, it's one truly novel innovation (from a mainstream language perspective) is it's lifetime system.

— таки готовится быть реализованной в C++, как мы выяснили. Далее автор говорит, что C++ после этого всё равно останется небезопасным потому что там останутся небезопасные фичи. Собственно, данная тема как раз про это — как при наличии небезопасных фич писать на C++ безопасно. И для этого будут инструменты (возможно, в компиляторах). Ну и не забываем про основную фишку C++:

The First Amendment to the C++ Standard states: «The committee shall make no rule that prevents C++ programmers from shooting themselves in the foot.»

Последний вопрос — про общую сложность C++. На него сам Страуструп по-моему уже давно ответил в том смысле, что не обязательно знать всё про язык, чтобы писать хорошие программы в какой-то определенной предметной области. С другой стороны именно чтобы не усложнять сам язык большинство новых фишек стараются добавлять в стандартную библиотеку, а не в синтаксис. И только при крайней необходимости затрагивают синтаксис. Между последними тремя стандартами изменений в синтаксисе на самом деле было мало, тем не менее профит получился огромным как раз в основном за счет стандартной библиотеки.

Ну и последний момент — про многоликий C++. Я лично не вижу ничего плохого в том, что язык позволяет использовать его настолько по-разному, что это иногда выглядит как совершенно разные языки. Это по-моему лучше, чем зоопарк действительно разных языков в одном проекте.

Когда оно сдохнет? Почему плюсисты не переходят на нормальные языки? Вечные вопросы, вобщем.

многоликий C++

Си++ - это несколько языков, совместимых только отчасти.

Почему плюсисты не переходят на нормальные языки?

Список таковых озвучите?

Си++ - это несколько языков, совместимых только отчасти.

Это намек на Си, препроцессор, ООП и шаблоны? Это известный упрек непризнанных экспертов по языкам, но, мимо. ООП и шаблоны совместимы прекрасно, препроцессор почти не нужен, а с Си Си++ несовместим не настолько сильно, чтобы это имело практическое значение.

Это намек на Си, препроцессор, ООП и шаблоны?

Это намек на Си, Си++ образца 1991 года и C++14.

Это известный упрек непризнанных экспертов по языкам

Эксперты советуют тебе приложить лед к пораженному участку тела.

с Си Си++ несовместим не настолько сильно, чтобы это имело практическое значение

фейспалм.жпг

Наверное, из-за несовместимости с Си постоянно приходится напоминать «Си и Си++ - разные языки».

Это намек на Си, Си++ образца 1991 года и C++14.

Тогда это вообще ни о чем.

Наверное, из-за несовместимости с Си постоянно приходится напоминать «Си и Си++ - разные языки».

Нет, просто в Си++ код для той же задачи обычно выглядит гораздо проще и работает гораздо надежнее.

Список таковых озвучите?

Он общелиспер, потому вероятность получить от него адекватный ответ равна 0.

в Си++ код для той же задачи обычно выглядит гораздо проще и работает гораздо надежнее

«Тем не менее, хорошие программы на языке С по сути являются программами на С++. Например, все программы из классического описания С [8] являются программами на С++» (ц)

Ну да, теперь, когда есть C++14 и планируется инструмент проверки и нормальное разбиение на подмножества, будет щастье. Для программ, написанных с нуля.

Для программ, написанных с нуля.

И не только, т.к. совместимость не ломают, то можно постепенно рефакторить старый код. Я с неделю назад натравил clang-modernize на старый проект, он мне override, auto, range for и пр. расставил. Это конечно больше «косметика», но зато автоматизированная.

Common Lisp, C#, Scala