Как стать автором
Обновить
222
58.5
Antony Polukhin @antoshkka

Эксперт-разработчик C++ в Яндекс Go

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

Вот например, угадайте язык программирования:
                    _mm_sub_pd(
                        _mm_mul_pd(distance, _mm_set1_pd(1.5)),
                        _mm_mul_pd(
                            _mm_mul_pd(_mm_mul_pd(_mm_set1_pd(0.5), dsquared), distance),
                            _mm_mul_pd(distance, distance),
                        ),
                    )

Правильный ответ: почти все бенчмарки «n-body» на этом сайте имеют этот кусок кода.

К несчастью в бенчмарках все языки на горячем пути как правило только вызывают C функции (см _mm_* и unsafe). Поэтому бенчмарки сравнивают как оптимизаторы разных версий GCC и Clang умеют оптимизировать C код, вместо того чтобы действительно сравнивать языки.

Ну и ничего удивительного, что bleeding edge версия clang-9 (2019), побеждает GCC-9 (2018) на числодробильных задачах.
если в libcxx не закомичены — придётся писать свои
std::stable_sort аллоцирует буфер под капотом. Можно этот буфер использовать. В случае, если буфер получилось выделить, итераторы random access, и value — интегральный тип — то вызывать вашу сортировку. Так и интерфейс не изменится, и работать будет быстрее.
Она динамически аллоцирует, что противоречит требованиям std::sort. Давайте тогда начнём с std::stable_sort для интегральных типов. Попробуйте сделать патч для libc++ github.com/llvm-mirror/libcxx и побенчмаркать
Порядок работы — разгребать по мере сил и возможностей. Если появляются добровольцы — выдаю задания попроще, если нахожу разработчика компилятооов — выдаю хрдкор, остальное — в основном по популярности
Да, увы, даже с правками соберётся.

Вся надежда на -Wlifetime godbolt.org/z/U_eG-H
1) Странно, вроде бы они не настолько медленные. Флаг std::ios_base::binary не помогал? В комитете недавно началась работа над async файловым вводом/выводом, к C++26 возможно сойдётся.
2) Это известная проблема, сейчас думают втащить github.com/hanickadot/compile-time-regular-expressions чтобы её починить
3) На подходе lock-free queue
4) Есть в Parallelism TS, SIMD будет уже в C++23
5) Начали обсуждать, когда будет готово — не известно
6) Потому что они медленнее std::sort. Если это не так — говорите, сделаем PR в стандартные библиотеки
7) Никто не предлагал. Как говорит Юсутис «Это ваша вина!< вы не предложили>»

Если вам нельзя аллоцировать в процессе работы, то вы вынуждены использовать freestanding часть стандартной библиотеки. Она именно для этого и для embedded сделана. Вроде бы всё ОК, или я не замечаю какую-то проблему?
В комитете любят шутить «We are consistently inconsistent»
Почти все языковые новинки C++20 уже обкатаны и есть в компиляторах. Только вот разные новинки — в разных компиляторах.
В предложении yield контекстно зависимый, потому старый код для работы с финансами и для подсчета урожая кукурузы не сломается
В C хотят взять C++ синтаксис для атрибутов (например [[likely]] ), wide_int, throws (который std::expected на уровне компилятора). За остальными новинками я особо не смотрел, но удивлюсь если у C комитета нет планов на Юникод и to_chars/from_chars
float/double уже можно использовать в constexpr и consteval. Их даже шаблонными non type параметрами можно использовать в C++20.

А вообще есть планы на unbounded float и разновидности decimal. Успеют ли они воплотиться в будущем Numbers TS — увидим
Они для того и пишутся, чтобы их кто-то читал )
Решили что «лучше страшненькие корутины сейчас, чем страшненькие корутины потом». Улучшать можно бесконечно, когда-то надо и релизить. ~10 лет — достаточный срок для тестирвания и разработки.
По более старым бумагам я могу давать информацию или любой другой человек из комитета. + могу выдавать стенограмы обсуждений отдельных бумаг, если вы работаете над смежной темой.
Верно, но увы, этого джина выпустили ещё в начале 90х и до сих пор не могут загнать в бутылку. Concepts из стандарта пытаются требовать чтобы присваивание и конструирование вели себя одинаково. Но язык всё ещё позволяет делать их разными.

В данном конкретном случае выбор между консистентностью или безопасностью :(
Первый пример — вызов assignment operator
Второй пример — вызов конструктора. Второе трогать не предлагали, только присвоения должны были попасть под static_assert
У них разные характеристики:
* stackfull позволяют пользователям фреймворка не задумываться о внутренней реализации, о co_await, co_return
* stackless быстрее отменять и они расходуют меньше оперативной памяти

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

И это я ещё не упоминал проектирование вашей квартиры, выдачу вам зарплаты, лечение в больничках, дальние путешествия, дизайн всего подряд, кино, мультфильмы, научные исследования…

Но да, сфера узковата, надо расширять. Тут я согласен
Boost.Coroutine2 используем )

Информация

В рейтинге
89-й
Откуда
Россия
Работает в
Зарегистрирован
Активность