• С++20 на подходе! Встреча в Рапперсвил-Йона
    0
    А потом, чтобы можно было всем этим пользоваться, добавить секцию unsafe. И получить то же, что имеем сейчас, только с unsafe {}
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    +1
    В комитете есть отдельная подгруппа, которая занимается тулингом. На последнем заседании они как раз обсуждали пакетные менеджеры, собирали требования к ним и пересылали все эти требования всем известным разработчикам пакетных менеджеров.
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    0
    +1. Всё что есть в Python и C# из коробки, должно быть и в C++ из коробки.
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    +1
    Offtop: кстати, девушка с видео есть на фотке из поста
    Offtop^2: главный нелюбитель фоток (Бьярни) спрятался за мной, пока я фоткал фотографа.
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    0
    Разные компиляторы умеют выводить эти атрибуты в разной степени. Думаю вы не будете рады, если у вас код с контрактами соберётся на одном компиляторе, а на другом будет говорить «error, not pure»
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    0
    На этапе компиляции код для рантайм проверки контракта может не генерироваться, однако компилятор необходимые ему данные сможет из контракта вытащить и использовать при оптимизации последующего кода.
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    0
    GCC должен уметь такое выводить. Попробуйте перепроверить, где-то на уровне IR должна выставиться инфа о том что функция pure.
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    0
    Ассерт выкидывается препроцессором и компилятору не перепадает информация о том, что данная ситуация из ассерта не может произойти при штатном выполнении. Ассерт находится внутри функции и компилятор не может достать информацию о валидном использовании функции, если он видит только forward declaration.
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    0
    Там во многих местах при работе контрактов нарочно поставлены UB.

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

    А до тех пор, комитет решил выпустить контракты в минимальном виде. Виде, который подходит для использования в стандартной библиотеке и для использования в кодовых базах ряда крупных компаний.
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    +1
    Не делать их :)
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    +1
    Увы, пока нет. Но в контрактах очень заинтересованы крупные компании, скорее всего имплементация появятся в скором времени.
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    +1
    Верно. Распишу поподробнее:

    Когда вы собираете проект, каждый cpp файл может компилироваться параллельно (это хорошо, отличная масштабируемость).

    Вы верно написали про раздувание на 1к1к строк. Дополнительной проблемой является то, что макросы из одного заголовочного файла могут влиять на содержимое другого заголовочного файла. Из-за этого компилятор не может кешировать разобранные заголовочные файлы, так как при изменении порядка инклюдов может поменяться их содержимое.

    Ещё одна проблема — невероятно количество макросов (они пораждаются например include guards). Держать их всех в памяти и препроцессировать документ становится тяжёлой задачей.

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

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

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

    И наконец, финальная стадия сборки проекта — линковка. В данный момент линковщик много времени тратит на выкидывание одинаковых блоков скомпилированного кода (вы подключили <string> 100 раз — линкер выкинет 99 скомпилированных std::string). С модулями линкеру не придется этим заниматься, т.к. файл модуля не будет вкомпиливаться внутрь собранного cpp файла.

    Но при этом НЕ ускоряется стадия оптимизации вашего кода. Если большую чать времени компилятор оптимизирует вашу программу — большого ускорения компиляции не ждите.
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    0
    Эти две статьи пересекаются, но не являются подмножествами друг другу :)
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    0
    Пока что, любой side effect является Undefined Behavior. Скорее всего так и останется.
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    0
    Кто же спорит — указатели в Rust самые правильные!

    Жаль только что пользоваться ими не удобно, оттого и серьёзных програм на нём нет.</troll-mode>
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    +2
    Есть история с Python3, которая пугает всех в комитете.

    Если мы сделаем std2, то как заставить пользователей на него быстро переехать? Если переезжать долго, то придётся десяток лет развивать две версии стандартной библиотеки, получать лучи ненависти от людей, вынужденных мигрировать на новую версию библиотеки…

    А главное — в чём плюсы то? Пока что, всё что хочется, все новые фишки, можно добавлять к стандартной библиотеке не ломая обратную совместимость.
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    0
    Странно записывать std::visit во что-то древнее, ему ведь всего 1 годик :)

    Так что конкретно вы хотите изменить в стандартной библиотеке? Какие основы хотите пересмотреть?
  • С++20 на подходе! Встреча в Рапперсвил-Йона
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    0
    Вы правы. Закиньте идею на stdcpp.ru, чтобы она не потерялась. Я автору предложения передам ваши возражения, думаю он прислушается
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    0
    А что бы вы хотели такого сделать в стандартной библиотеке, что поломает обратную совместимость? Концепты и контракты можно добавлять к уже имеющимся классам стандартной библиотеки, и всё будет OK.
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    +1
    Метаклассы базируются на рефлексии, рефлексия требует constexpr контейнеров и алгоритмов.

    Constexpr алгоритмы мы дотолкали до стандарта. Надеемся увидеть в C++20 constexpr контейнеры; рефлексию — в C++23. Где-то в это время и появятся метаклассы в стандарте.
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    +2
    Работать 10 лет и получить прирост скорости компиляции на 10% больший чем дают precompiled headers — это провал. Люди работающие над clang — одни из авторов ATOM. Можно приблизительно представить, какой прирост производительности с подходом из ATOM можно получить.

    Один из разработчиков Modules TS утверждает, что макросы — одна из основных причин тормозов. Поэтому пока вы не начнёте использовать модели без макросов — довольствуйтесь 10% прироста скорости.

    Лично мне ATOM нравится простотой внедрения в большие кодовые базы, и не нравится своим небольшим приростом скорости компиляции.

    Modules TS и ATOM в gcc сделаны и информация об актуальном состоянии есть вот тут gcc.gnu.org/wiki/cxx-modules
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    0
    А какое имя вы предлагаете?
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    +1
    Но ведь по ссылке с макросами… :(
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    0
    И практически не получаем выигрыша в производительности :)
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    0
    Вангую что с метаклассами мы получим:
    * генерацию парсеров из EBNF и других форматов описания грамматик
    * ORM классов из коробки
    * сигнал/слоты Qt без макросов
    * расцвет DSL
    * красивый RPC
    * ???
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    +1
    Это текущий Modules TS (модули в первоначальном виде).

    Ряду компаний очень не понравилось отсутствие макросов и, как следствие, невозможность «модуляризировать» системные заголовочные файлы.
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    +2
    Думаю вам пока подойдёт вот эта библиотека. Есть её видео презентация от автора.

    Пример использования:
    constexpr auto re = "^(?:[abc]|xyz).+$"_pre;
    re.match(some_string);
    
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    +2
    Ну это кому как. Я контракты второй год с нетерпением жду, а std::bit_cast люди хотели ещё лет 20 назад…

    Ну и не стоит так надеяться на модули, в 10 раз они компиляцию не ускорят (в ближайшее время).
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    +1
    Полностью разделяю ваше мнение! Но в комитете много людей, и у них свои задачи и требования к фичам языка.

    Кому-то не нравится вариант 3, так как из сигнатуры функции не понятно что это шаблонная функция (нужно знать, что Copyable — это концепт; проблем не возникает в случае со стандартными концептами, однако для больших кодовых баз со множеством своих концептов разобраться будет намного сложнее).

    Кому-то не нравится вариант 2, потому что он громоздкий :)
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    0
    По модулям будет отдельная встреча этим летом. Будут обсуждать только модули.

    Буквально 2 заседания назад появилось новое предложение по модулям, позволяющее экспортировать макросы и упрощающее миграцию старого кода на модули. На ближайших заседаниях будут пытаться слепить старые и новые предложения в одно. Общее предложение скорее всего будет сначала выкачено в эксперимент (в виде обновленного Modules TS), и только после этого смержено в стандарт. В общем, шансы увидеть модули в C++20 есть, но они не велики.

    Сопрограммы скорее всего войдут в C++20. Были попытки выдвинуть другое (конкурирующее) предложение по сопрограммам. Поддержки новый подход не получил. Если новых предложений или возражений не поступит, то Coroutines TS окажется в C++20.
  • С++20 на подходе! Встреча в Рапперсвил-Йона
    +2
    Required clause (1) вошли и будут в C++20.
    Варианты 2 и 3 активно обсуждаются и полируются, в них есть проблемы:
    • Вариант 2 не позволяет работать с концептами принимающими сразу два шаблонных параметра
    • Вариант 3 вызывает недоумение в случае
      void foo(Copyable x, Copyable н);
      Типы у переменных x и y должны быть одинаковые или нет?


    А есть ли возможность сделать перегрузки constexpr/runtime для функций?

    Идёт работа над волшебной функцией is_constant_evalueated(). Она позволит внутри функции делать ветвление, в зависимости от того, выполняется функция на рантайме или на этапе компиляции:
        constexpr double power(double b, int x) {
          if (std::is_constant_evaluated() && x >= 0) {
            // A constant-evaluation context: Use a
    	// constexpr-friendly algorithm.
            double r = 1.0, p = b;
            unsigned u = (unsigned)x;
            while (u != 0) {
              if (u & 1) r *= p;
              u /= 2;
              p *= p;
            }
            return r;
          } else {
            // Let the code generator figure it out.
            return std::pow(b, (double)x);
          }
        }


    Какой статус у Ranges?

    Идёт активная работа по принятию из в C++20. Есть все шансы на успех.
  • C++ велосипедостроение для профессионалов
    0
    А какой алгоритм для выбора кэш линии внутри корзинки? Он явно отличается от LRU, на который я опирался в своих рассуждениях.

    Длительное же время во многих CPU был LRU, из-за которого в 4-way кэше, 4 новых значения для корзинки вытесняли все старые значения (вне зависимости от того, как часто они использовались до этого).
  • C++ велосипедостроение для профессионалов
    +1
    Это постарались исправить в C++17, добавив std::to_chars/std::from_chars.

    Так что у меня слабая надежда, что со временем велосипеды сойдут на нет.
  • C++ велосипедостроение для профессионалов
    0
    Я с вами полностью согласен.

    Помимо рассмотренных вами приложений, работающих с небольшими наборами данных, есть приложения, где узкое место — память, и активный датасет занимает несколько мегабайт. В таких приложениях, дополнительно наращивая объёмы данных, которые надо хранить в кеше, вы вытесняете что-то полезное из l1/l2/l3.
  • C++ велосипедостроение для профессионалов
    +3
    Давайте на секундочку забудем весь предыдущий диалог.

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

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

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

    Возможно, контекст что пример cpu bound, возник из-за специфики вашей работы, где вы решаете cpu bound задачи.

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

    Ну и наконец. Подавляющее большинство людей, с которыми вы общаетесь на этом сайте, являются профессионалами своего дела. Ваша точка зрения не единственная правильная. А если вы уверены, что вы правы, то надо оппоненту не грубить, а объяснять максимально мягко, обоснованно и безэмоционально.
  • C++ велосипедостроение для профессионалов
    +1
    Вы дурачок или прикидываетесь?

    Вы собираетесь тупо складывать летенси инструкций исполняющихся на разных портах?

    Давайте перенесём нашу дискуссию на лето, когда сезонное обострение пройдет, и вы сможете подробно и аргументированно (со ссылками на сторонние источники), без истерик и ругани, расписать как вы видите этот пример и почему вдруг вы выкидываете кеши/доступы к памяти из картины.
  • C++ велосипедостроение для профессионалов
    +1
    Ознакомьтесь с вот этим и найдите отличия с тем, что делаете вы.

    Прежде чем вступать в дальнейший диалог, прошу вас так же выучить вот это.
  • C++ велосипедостроение для профессионалов
    0
    Эта клоунада. Я вас поймал уже с десяток раз, а вы меня ноль.


    А давайте клоуна найдет не предвзятый свидетель спора. Расскажите в какой компании работаете и как вас зовут.

    Интересно, ваше руководство в курсе о наличии в рядах сотрудников столь ценных кадров?
  • C++ велосипедостроение для профессионалов
    +1
    Подобные выводы не имеют смысла. И опять же, глупая попытка врать. Куда вы потеряли все остальные тезисы? Про «тратить 1кб памяти»? Расскажите мне о том, как оно тратит 1кб памяти. Что же вы не пытаетесь?


    Кеши устроены в виде хеш таблицы, где корзинка выбирается как (memory address) / (line size) % (number of sets), а в корзинке хранится обычно 4 элемента. Итого: какими бы мусорными данными не были, они выкинут одно данное из строго определённой корзинки.

    Соответственно чтобы протерять 1Kb кеша достаточно пройтись по данным с шагом 64 байта. Это затронет максимум корзинок.

    Чтобы не позорится в дальнейшем, ознакомьтесь с «Optimizing software in C++» от Agner Fog. Там есть немного плохих советов, но низкоуровневые вещи расписаны верно.