Произошло очередное заседание комитета C++

Свежий обзор очередной части принятых в C++23 нововведений от Антона Полухина: https://habr.com/ru/company/yandex/blog/678760/

Его предыдущие отчеты о прогрессе C++23:

https://habr.com/ru/company/yandex/blog/649497/ (февраль 2022)

https://habr.com/ru/company/yandex/blog/580880/ (октябрь 2021)

https://habr.com/ru/company/yandex/blog/561104/ (июнь 2021)

https://habr.com/ru/company/yandex/blog/527938/ (декабрь 2020)

спасибо, почитаю.

Networking опять на потом.

import std;

Нужно. Остальное минорщина.

Ан, нет. Ещё std::start_lifetime_as. Мне такое нужно в кастомных бинарных протоколах.

Removing Garbage Collection Support

:)

import std;

Нужно. Остальное минорщина.

Да они охренели. Одним оператором ВСЮ стандартную либу – и плюсовую, и сишную. Оно вообще реализуемо? И сколько памяти надо, чтобы компилятор это через себя провернул? UPD: Вспомнил как красиво в жаве по иерархическим packages всё разложено. А здесь… как был бардак, так и остался.

Ещё про #elifdef / #elifndef поржал: не прошло и двухсот лет, как запилили очевидную вещь, которая должна была быть сделана в первой же версии препроцессора.

Ещё stacktrace давно пора. Правда я не вчитывался, может они хотят испортить идею реализацией.

Да они охренели. Одним оператором ВСЮ стандартную либу – и плюсовую, и сишную. Оно вообще реализуемо? И сколько памяти надо, чтобы компилятор это через себя провернул?

https://www.reddit.com/r/cpp/comments/w50v6i/standard_library_modules_bug_bash/

Сейчас проходит бета тест среди желающих. Уже нашли 2 проблемы.

размер модуля std:

std.ifc = 26 485 117 std.obj = 4 279 674

сколько оперативной памяти я не знаю. Но вроде немного.

Да они охренели. Одним оператором ВСЮ стандартную либу

Ты не забывай, что это не обычный include с текстом, а модуль. Там спец формат для быстрого и удобного парсинга.

Как вам новые добавленные возможности и что ждёте больше всего?

Как в том стихе: «Уж не жду от жизни ничего я, и не жаль мне прошлого ничуть» :) Что в переводе означает «пока и 17го хватает».

пока и 17го хватает

Маловато, надо 20. Концепты - чистое добро. Как в свое время ключевое слово override. Я новые проекты под c++20 начинаю.

А чо, какой-то оптимизатор уже портит твой код без этого? 🤡

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

Скажи ещё, доступ к object representation нужен.

«Removing Garbage Collection Support»

Куда! Зачем!

«Removing Garbage Collection Support»

Куда! Зачем!

он был «Optional».

И gcc, clang, MSVC выбрали no-op реализацию, так как необязательный :)

И сколько памяти надо, чтобы компилятор это через себя провернул?

Если оно нормально сделано (хэш табличка пригодная к mmap) то ноль.

Не нужён. POD есть и хватит.

А как вы смотрите на алгоритмы из std:: и из std::ranges:: ? Считаете ли, что первые будут deprecated (по мне - да)?

Что думаете по поводу всего этого дубляжа std::/std::ranges::begin, end, size, ssize, etc? Собираются ли деперекейтить стд’шные?

Ты участвуешь в работе какого-то комитета по C++? Иначе как ты всегда в курсе…

std::ranges

Не готов как линукс к десктопу. Перемудрили с ленивостью. Как-то нужно было разбить строку на подстроки и выплюнуть эти подстроки в виде std::string_view. Решил попробовать сделать на модно-молодёжных рэнжах. В итоге после получасового чтения портянок с ошибками компиляции в шаблонах, рэнжи были выкинуты и заменены на православные циклы.

я единственный кто считает что комитет подложил свинью с flat_map/flat_set ?

или есть единомышленники ?

Ты участвуешь в работе какого-то комитета по C++? Иначе как ты всегда в курсе…

Чат читаю (и пишу иногда) https://discord.gg/6bYEZJtq

Он публичный и доступен для всех желающих…

Что за дичьдискорд? C++ обсуждают в слаке.

C++ обсуждают в слаке.

Кто?

Разработчики компилятора и стандартной библиотеки Microsoft С++ создали https://discord.gg/6bYEZJtq

Разработчики LLVM тоже создали https://discord.gg/wAhq5pvB

Понятно что в обоих каналах кроме создателей полно ещё всяких людей с которыми можно поговорить…

А кто сидит в слаке? Разработчики GCC?

Кто?

cpplang.slack.com

я единственный кто считает что комитет подложил свинью?

Нет, не единственный.

я единственный кто считает что комитет подложил свинью с flat_map/flat_set ?

А где там свинья?

А кто-нибудь в курсе, в чём была проблема наделить reinterpret_cast свойством создания новых объектов вместо введения нового start_lifetime_at? Ну помимо желания добавить что-то новое.

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

Ты std::bit_cast имеешь ввиду?

Я не настоящий сварщик, просто некоторое время назад пришлось погрузиться в тему std::launder. Как я понял, необходимость в std::launder возникает из-за того, что компилятор может применять некие оптимизации, которые он не должен был бы применять. Так что std::launder – это своего рода барьер для оптимизатора.

Если наделить reinterpret_cast свойствами такого барьера, то это может негативно сказаться на производительности.

Рискну предположить, что за std::start_lifetime_as скрывается аналогичная мотивация.

Ссылки, которые могут быть полезны: https://miyuki.github.io/2016/10/21/std-launder.html

https://habr.com/ru/post/540954/

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0593r6.html

Кто как вычисляет циклические зависимости заголовочных файлов.

Спасибо, ссылки интересные. Вроде даже понял, на кой нужен std::launder.

Производительность дело хитрое, в особенности потенциальная производительность.

Но учитывая то, сколько кода понаписано с reinterpret_cast’ами из массива в объект и наоборот, компиляторам в любом случае придётся оставлять такие барьеры, иначе всё сломается.

Removing Garbage Collection Support

Оно было?

Но учитывая то, сколько кода понаписано с reinterpret_cast’ами из массива в объект и наоборот, компиляторам в любом случае придётся оставлять такие барьеры, иначе всё сломается.

А почему компиляторостроители должны заботиться о программистах, понапихавших UB в свой код?

В лучшем случае сохранят старое поведение для стандартов до C++17, а при компиляции в новых стандартах оптимизаторы начнут плевать на такой UB в коде.

Тут же еще и философский вопрос: должны ли будущие поколения программистов платить за криворукость предыдущих поколений?

Насколько я понял – чисто формально было. Возможно без какой-либо вообще реализации.

А кто-нибудь в курсе, в чём была проблема наделить reinterpret_cast свойством создания новых объектов

Ну, я против, например.

Смогут не платить, как токо сами научатся сразу делать как надо в условиях многокритериальной оптимизации, чтоб за их криворукость в свою очередь никто не платил. (Т.е. никогда :))

В слаке теперь обсуждают сейлфорс :)

Думаю, что вся возня примерно вокруг этого:

#include <iostream>
#include <new>
using namespace std;

struct B {
     virtual void fn() {cout << "kjk" << endl;}
};
struct D : B {
     void fn()override {cout << "qqq" << endl;}
};

void call(int *p) {
     reinterpret_cast<B*>(p)->fn();
        leaq    8(%rsp), %rdi
        call    D::fn()
     launder(reinterpret_cast<B*>(p))->fn();
        leaq    8(%rsp), %rdi
        call    *vtable for D+16(%rip)
}

int main() { 
     D d;
     call(reinterpret_cast<int*>(&d));
}

Т.е. научить reinterpret_cast быть более человеколюбивым == замедлить кому-то что-то.

должны ли будущие поколения программистов платить за криворукость предыдущих поколений?

Ну уже платят и продолжат платить. В идеале, конечно, они могут сломать совместимость и порушить reinterpret_cast. Но на практике компилятор, который это сломает первым проиграет первым, так что вряд ли кто-то на такое пойдёт. В особенности учитывая, что значительный прирост производительности вряд ли будет. Тут на -no-strict-aliasing до сих пор вроде плачутся при переходе с msvc на gcc, а это так-то по-основательнее будет.

Ну и вообще говоря это всё косяк стандарта имхо, а не программистов, т.к. в стандарте явно обозначено, что кастовать правильно выровненный uint8_t* в объект можно, ровно как и наоборот. А дальше выясняется, что объект не создаётся и это ub в одной части стандарта, и разрешено в другой. Да и вообще модель памяти C++ полна максимально странных ограничений, созданных ради каких-то воображаемых абстрактных машин. Имхо, лучше бы было ближе к реально существующему железу, ну или вообще не было как в сишечке. Впрочем, весьма вероятно это я чего-то не понимаю.

Ну, я против, например.

Почему?

Ну насколько я могу судить сейчас в мейнстримных компиляторах поведение reinterpret_cast не отличается от предполагаемого поведения start_lifetime_at, просто оно не стандартизировано. Более того, start_lifetime_at и reinterpret_cast будут по-прежнему noop, просто первый будет официально создавать объект, как new, malloc, memcpy и т.п.

Я в ассемблере ничего не понимаю, но что-то мне подсказывает, что если заменить в примере reinterpret_cast на start_lifetime_at, то ничего не изменится.

bit_cast тут немного не при делах. Он копирует объект. Тут речь про reinterpret_cast uint8_t* в объект и наоборот, без копирования.

reinterpret_cast нельзя использовать в constexpr выражениях

В идеале, конечно, они могут сломать совместимость и порушить reinterpret_cast. Но на практике компилятор, который это сломает первым проиграет первым, так что вряд ли кто-то на такое пойдёт.

Лет 8 назад был же скандал, когда GCC перестал работать на коде вроде вот такого:

static int podhd_try_init(struct usb_interface *interface,
        struct usb_line6_podhd *podhd)
{
  int err;
  struct usb_line6 *line6 = &podhd->line6;

  if ((interface == NULL) || (podhd == NULL))
    return -ENODEV;
  ....
}

Даже, емнип, большой скандал был с участием Линуса.

И что, GCC проиграл?

Я что-то такое даже помню, там гцц решил, что если есть обращение к члену, то указатель точно не null и выкинул проверку.

Чёрт его знает, посмотрим. Может и сломают.

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

Если посмотреть на это с точки зрения чистой математики, как это ложиться на ассемблер то:

a = b+offset;
if (b==0)
  return -ENODEV;

Да. Но гцц решил, что если обратились к объекту, то указатель на него не null. Собственно потому и был весьма большой скандал, что однозначной ошибки в коде там не было.

однозначной ошибки в коде там не было.

компиляторы и сейчас говорят что это UB:

https://gcc.godbolt.org/z/Kj4aq8a5G