• C++ быстрее и безопаснее Rust, Yandex сделала замеры
    0
    Вторая часть определения — отличная! Жаль что вместо таких определений в лучшем случае говорят «безопасное подмножество Rust защищает от ошибок, связанных с многопоточностью, гонками данных и выстрелами по памяти.»
  • C++ быстрее и безопаснее Rust, Yandex сделала замеры
    –8
    Ну тогда и говорите это окружающим «От определенного типа багов Rust спасает». А то толпы людей верят, что Rust от всего защищает, в нём нет UB, переполнений чисел и невозможно допустить багу в принципе.
  • C++ быстрее и безопаснее Rust, Yandex сделала замеры
    –8
    > Надо ли говорить, что из посылки совершенно не следует вывод?

    Давайте распишу по шагам, коль вы тут увидели уловку:

    >> Миф №2. Плюсы Rust только в анализе времени жизни объектов.
    > Это заявление ложно, так как безопасное подмножество Rust защищает от ошибок, связанных с многопоточностью, гонками данных и выстрелами по памяти.

    Итак, с многопоточностью безопасное подмножество Rust ошибку не нашло, значит Rust не защищает от ошибок с многопоточностью.

    Бесконечная рекурсия на простом примере тоже не очень отработала. Спишем на багу в LLVM. Однако, на более сложных примерах LLVM не справится с детектированием бесконечных рекурсий (см. проблема остановки) и во время работы приложения будет выеден весь стек и будет выстрел по памяти в безопасном подмножестве Rust. То есть и с памятью Rust не помог.

    Что остаётся у Rust из преимуществ, по сравнению с C++?

    Возможно автор имел в виду «Это заявление ложно, так как безопасное подмножество Rust частично защищает от ошибок, связанных с многопоточностью, гонками данных и выстрелами по памяти.». Но в статье то написано не это, люди воспринимают Rust как 100% защиту от багов. И, к несчастью, подобное введение в заблуждение в подавляющем большинстве статей про Rust.
  • C++ быстрее и безопаснее Rust, Yandex сделала замеры
    –3
    Попробуйте отказаться от софизмов в технических постах:
    * не меняйте тему обсуждения. Вы подменили «Плюсы Rust только в анализе времени жизни объектов» на «deadlock — это не неопределённое поведение, всё хорошо». Или вы так ненавязчиво согласились, что Rust безопасен только для lifetime?
    * Не возлагайте бремя доказательства на другого. Я в выступлении показал неэффективность. Если хотите доказать, что обращения к памяти бесплатны — доказывайте.
    * не делайте необоснованных утверждений, наподобие «Накладные расходы, одинаковые и для C++.». Calling convention в C++ и Rust разный, Rust вынужден перекладывать больше параметров на стеке (да, опять трогать память). Посмотрите примеры, я их где-то в соседних выступлениях приводил.

    > Под заголовком слайда «Программа написанная на языке Rust X не содержит ошибок» в топике про Rust и перед тем как вы перешли на C++ vs Go? Ок…

    И правда… Хм, когда-то я задумывал этот слайд в ответ Хаскелистам, про то что написал там Rust уж и забыл :)
  • C++ быстрее и безопаснее Rust, Yandex сделала замеры
    +12
    > Миф №1. Арифметика в Rust ничуть не безопасней C++

    То есть вы считаете нормой, что перемножив 46341 в Rust в релизе вы получите -2147479015 а не аналог исключения. Это ничуть не безопаснее.

    > Миф №2. Плюсы Rust только в анализе времени жизни объектов.
    > Это заявление ложно, так как безопасное подмножество Rust защищает от ошибок, связанных с многопоточностью

    В Rust без вских unsafe можно получить deadlock doc.rust-lang.org/std/sync/struct.Mutex.html

    Основная причина — невозможность выразить необходимое в системе типов Rust. Поэтому да — только lifetime (что включает в себя немного гонок, и выстрелов по памяти)

    > Миф №3. Вызовы функций в Rust бездумно трогают память.

    Выше сравнение по ссылке godbolt.org/z/C5ADqM — неверное. Если вы сравниваетесь с отключенными проверками в Rust, отключайте их и для C++ godbolt.org/z/fh8_U2

    > Миф №4. Rust медленнее C++.
    > Складывается впечатление, что весь этот анализ ассемблерного выхлопа был нужен лишь для того, чтобы сказать, что больше асма → медленнее язык.

    Прочитайте пожалуйста внимательнее ассемблер. Это код без условных переходов, а инструкции наподобие `mov dword ptr [rdi], ecx` трогают оперативную память. Пожалуйста не приписывайте мне ваши неверные выводы.

    > Миф №5. C → С++ — noop, C → Rust — PAIN!!!

    Да, штатный пакетный менеджер помогает замять множество проблем. Первоначальная проблема от этого остаётся.

    > Миф №6. unsafe отключает все проверки Rust.

    Забавно, что в другом разделе документации имеется неполный список UB doc.rust-lang.org/reference/behavior-considered-undefined.html, который практически полностью совпадает с C++ списком. Обратите внимание на термин «unsound», подразумевающий что код после unsafe может взорваться в любом месте. Так что да, unsafe все проверки убивает.

    > Миф №7. Rust не поможет с сишными библиотеками.

    Только вот мало какая С библиотека нынче поставляется с LTO. Так что накладные расходы пока есть. Ну и про unsafe см выше, вы не можете использовать C без unsafe.

    > Миф №8. Безопасность Rust не доказана.

    В выступлении эта часть была про Хаскель :) Но процитируйте пожалуйста полностью эту часть выступления, вы парировали только треть (да и то не до конца честно, см UB в Mutex).

    > Заключение
    > Однако от признаных экспертов я ожидаю взвешенного освещения ситуации, которое, как минимум, не содержит грубых фактических ошибок.

    К несчастью в вашем ответе грубых ошибок по паре в каждом пункте, нет убедительных опровержений, а работало над ответом аж 3 человека. Попробуйте подойти более ответственно и честно к сравнению.

    На каждой ошибке я не останавливался, попробуйте найти их сами.

    P.S.: Ваш заголовок вводит в заблуждение. Никаких замеров в статье нет, нигде в выступлении такое не говорилось, Яндекс (насколько мне известно) вы не представляете. Получается очень некрасиво с вашей стороны
  • День смерти стандартной библиотеки
    +2
    GCC. Все коммерческие продукты, поставляемые в бинарном виде для Linux, надеются на неизменность ABI, благодаря чему они могут не пересобирать свой продукт под каждый новый дистрибутив.

    Разумеется можно сломать ABI, но тогда коммерческие продукты вынуждены будут либо
    * собирать только под новый ABI, и забросить поддержку старых платформ
    * собирать только под старый ABI (потому что он везде поддерживается), и тогда новый ABI немного теряет смысл.
    * собирать под новый и старый ABI, что они навряд ли захотят делать
  • День смерти стандартной библиотеки
    +8
    Немного нечестно с моей стороны писать тут, потому что cor3ntin не знает русского, но:
    * «Сделать ассоциативные контейнеры (намного) быстрее» — нет, не «намного»! Предложенные изменения для стандартных контейнеров ломают в первую очередь API, потому что они убирают методы для работы с нодами и итерации по корзинкам.
    * «Ускорить работу std::regex (На данный момент быстрее запустить PHP и выполнить на нем поиск по регулярному выражению, чем использовать стандартный std::regex)» — основное что тормозит в std::regex, это локали. Убрать локали — это изменение API а не ABI.
    * «Некоторые изменения в std::string, std::vector, а также в разметке других контейнеров» — скорее всего речь идёт про добавление SSO в vector, а это прежде всего ломает его гарантии по инвалидации итераторов. То есть это опять слом API а не ABI.
    * «Единство интерфейса классов: на данный момент некоторые их реализации намеренно не соответствуют единому интерфейсу в угоду стабильности ABI» — да, это осознанное решение одного единственного вендора. И что бы не решил в этом месте комитет — это личное дело вендора, когда именно ломать ABI. Планы комитета стандартизации, которые пойдут в разрез с планами вендора, будут проигнорированы. Ибо от ABI зависит бизнес вендора и его финансовое благосостояние.
    * «Предложение добавить фильтр в recursive_directory_iterator было отклонено, потому что сломало бы ABI» — оно было отклонено, потому что оно дурное. Автор предложения неправильно написал бенчмарк, что сводило полезность и достоверность его предложения на 0.
    * «Предложение сделать большинство функций из библиотеки constexpr (включая strlen) скорее всего тоже будет отклонено, ведь ломает ABI» — это можно реализовать без слома ABI. Комитет отправил нас исследовать этот вопрос, мы поисследовали, всё ОК.

    Ну и в целом: голосование решило что форсить слом ABI не будем, потому что вендоры могут не поддержать; голосование сказало что при наличии достойной идеи ломать ABI — это ОК. Трагедии особой не вижу. Единственная проблема — голосование получилось нейтральным, из-за этого противники и сторонники слома одинаково недовольны.
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    0
    Если вам чего-то не хватает в существующем предложении — пожалуйста, изложите подробно свои мысли и, желательно, напишите proposal. Так же приложите ссылки на предлагаемые для включения прототипы.
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    +1
    Это проблемы в ItaniumABI. Чтобы поправили, попробуйте полайкать вот эти тикеты:
    * github.com/itanium-cxx-abi/cxx-abi/issues/75
    * github.com/itanium-cxx-abi/cxx-abi/issues/77
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    0
    Тут поможет [[no_unique_address]]
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    0
    Мы с подобными предепреждениями боремся через атрибуты godbolt.org/z/RPVwRA:
    [[maybe_unused]] auto&& [] = RPCAdapter<void (*)(void)>(channel);


    А чем ссылка на void поможет в этом примере? Вы хотите чтобы structured bindings работали с void?
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    0
    Можно же void возвращать: godbolt.org/z/k6Hpsi
    А void переменные вы для чего хотите использовать?
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    +2
    За то время, что Networking варится в комитете, он стал ощутимо лучше (нормальная поддержка аллокаторов, хорошая реализация одинарного буффера...)

    Concepts позволяют сделать Networking ещё лучше. Одна из причин отсутствия Networking в C++20 — не успели доработать для него концепты
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    +1
    Вы наверное что-то путаете. AF_UNIX вам может пригодиться вне зависимости от поддержки IPv6, хотя бы потому, что он производительнее чем использование TCP/IP стека
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    0
    Они не опциональные, они все обязательные.

    Feature testing макросы сделаны для удобства разработчиков библиотек, на время переходного периода и для упрощения поддержки старых компиляторов.
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    0
    С предложенным выше подходом можно просто писать «Реализовали C++23», что звучит намного лучше чем какая-то экспериментальная поддержка
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    0
    Есть ещё Boost.Outcome
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    0
    Это большое усложнение языка ради небольшого выигрыша. Скорее уж надо пойти по пути введения в стандарте термина, обозначающего «при следующем сломе ABI». Тогда можно говорить «при следующем сломе ABI конструктор копирования tuple становится тривиальным для тривиальных типов»

    Так и вендоров мы не обязываем ломать прям сейчас, и оптимизацию в этом месте разрешаем.
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    +2
    В C++20 не будет. Обусждается для принятия в C++23 в виде библиотечного решения std::expected и в виде решения на уровне языка throws.
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    0
    Приведите пожалуйста примеры
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    +1
    Да, всё верно. Это теперь принято называть implicit construction, и оно срабатывает если у типа есть тривиальный конструктор и деструктор
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    +6
    Вас ассемблер покусал? ))
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    0
    Если у вас есть богатый опыт в работе с юникодом и какие-то идеи, то пишите proposal или просто сходите в подгруппу SG16: Unicode. Если есть какие-то замечания к существующим proposal — напишите мне, посмотрим что можно сделать
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    0
    Ranges и datetime — добавлили отличные библиотеки для рантайма
    Концепты — добавили для метапрограммирования и не только
    Модули — ускоряют компиляцию
    Корутины — позволяют использлвать нечто абсолютно новое
    Constexpr всякое — позволяют compile time вычисления делать с обычным синтаксисом
    Новые правила для тривиальных типов — ускорение рантайм кода


    Тут каждый аспект языка улучшили. Вы чего-то ещё большего хотели? Скажите хоть чего именно :)
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    +2
    Если вкратце — во всех возможных ситуациях. Он не alias-ится со всем подряд, из-за чего использование char8_t порождает более производительный код.

    Жаль только что он ещё мало где поддерживается стандартными библиотеками
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    0
    Там проблема глубже. На libstdc++.so.6 + libstdc++.so.7 проблемы только начинаются: вам нужно собрать отдельный Boost для libstdc++.so.6 и отдельный для libstdc++.so.7… фактически каждая популярная C++ библиотека удвоится.

    Поэтому обычно в рамках дистрибутива сразу переходят на новый ABI.

    Заметье, что в комитете предлагали сломать ABI на уровне ядра языка. В этом случае у вашего проекта возникают проблемы с поддержкой старых платформ — в C++ вы могли пользоваться новыми языковыми фишками и [очень]старой стандартной библиотекой, но при сломанном ABI вы так больше делать не можете. Новый компилятор будет просто выдавать бинарники не линкуемые со старым стандартом. Поэтому вы будете вынуждены разрабатывать под версию стандарта поддерживаемую всеми вашими платформами. А это замедлит внедрение новых стандартов C++, что не очень хорошая идея.

    Ломать ABI можно, но это должно быть осознанное решение вендора для конкретой реализации библиотеки, а не решение комитета на уровне языка. Форсирование слома ABI может быть не поддержано вендором, и мы получим стандарт C++ которым не будут пользоваться на какой-то платформе. Это очень нездоровая ситуация.

    Например, скажите разработчиком мобильных устройств, что им придётся продублировать все C++ библиотеки — узнаете много новых слов.
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    0
    Пример: Структура не создана, значит и запись в неё не имеет смысла и можно её не производить.

    Другой пример: структура не создана, а значит и последующие чтения из неё не имеют смысла и можно заменить на чтение 0.
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    +2
    Да, участвуют. Все предложения проходят через них, без их олобрения предложение принято не будет
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    0
    std::vector благодаря трейту is_nothrow_move_constructible решает, копировать ему элементы при resize, или же просто перемещать.

    Если трейт начнёт врать, то вектор возможно что всегда будет копировать. А это безумные замедления, никакие мнимые преимущества от noexcept их не перевесят.

    Кстати, добавьте noexcept к vector::back прям сейчас… и вы не увидите разницы в кодгене для GCC (остальные вендоры ленятся с правильной реализацией исключений)
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    +1
    Импортирование C++ хедеров обязано работать в C++20. import <iostream>; — это правильно, безопасно.

    Но не так быстро как import std.iostream;, который появится только в C++23
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    0
    Не очень понял вопрос. Приведите пожалуйста пример
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    +1
    Над пакетными менеджерами работают, но они никогда не зависели от успеха модулей. Так что даже без модулей, работа над стандартными пакетными менеджерами продолжалась бы.
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    +1
    Вошло в C++20. Успели в последний момент :)
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    +1
    1) Согласно букве стандарта раньше было нельзя так делать, но все делали. С C++20 теперь так делать можно.
    2) Постарался упростить. Если найдёте ещё сложные предложения — пишите в личку, поправлю.

    Ответы на вопросы второй части:
    1) да, фактически прочтым перевесом голосов
    2) Я очень надеюсь на Reflection в C++23, шансы увидеть его в ближайшем будущем высоки
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    +1
    В самом разгаре. Пока всё неочевидно и кажется что 10 раз поменяется
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    0
    > всегда найдется компания, у которой что-то сломается, и которые против изменений ради status quo

    И это хорошо до тех пор, пока не ломается код вашей компании, или код любимого вами приложения.

    > Тогда и логика будет «noexcept функция не кидает если контракт не нарушен», что логично и просто, и оптимизировать проверки контрактов компилятору будет проще

    Вас не смущает, что с таким подходом std::is_nothrow_* трейты вам будут врать и вы не сможете написать эффективные библиотеки? И что производительность вектора может ухудшится раз в 10?
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    +1
    Используйте это на свой страх и риск. Как будут выглядеть стандартные модули ещё не решено, только зарезервированы имена начинающиеся с std. Если к C++23 комитет решит сделать несколько другие имена модулей, код с вышеозвученными MS модулями немного поломается.
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    +4
    Хм, если Concepts, Coroutines, Modules, Ranges для вас небольшие изменения, то что же является большими?
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    +8
    Большинство известных мне компиляторов так не чудили

    Теперь все обязаны не чудить
  • C++20 утверждён! Чего ждать и к чему готовиться разработчикам в C++23
    +3
    До C++20 стурктура по адресу p не создавалась. Компилятор мог делать странные оптимизации, подразумевая что по p нет объекта