я не умею в 2д делать

Я недавно смотрел реализацию в folly:
* load
 * load + compare_exchange_weak
 * изредка дополнительные fetch_add + compare_echange_weak
 * еще реже может встать в спин лок
* store
 * exchange + fetch_sub

хм...

В store скорее всего есть еще fetch_add.

Ну 512 - это очень мало, если бы размер fft был несколько миллионов, то наверняка бы простой реализации не хватило.

я сейчас чекнул код, по коду вроде как оно 2к элементов преобразовывало в 1к каждые 3мс, при этом только одно ядро нагружено на треть (это с учётом рендера полученных графиков) может это и не быстро, но мне хватило, а быстрее может и имеет смысл взять готовую либу

про 3мс, я наверное всё-таки наврал, скорее всего 10

Здравствуйте. Есть следующая задача: есть подсистема RPC, которая умеет посылать и принимать надёжный поток 4кб фреймов. Есть потенциально куча потребителей этой системы, которые хотят посылать через неё большие блобы. Какой из rpc правильнее всего выставить наружу интерфейс, который потребители могли бы сабклассить, что-то похожее на интерфейс итераторов, но с виртуальными функциями? По сути это два класса, class SendStream { virtual std::optional<std::string> next_chunk() = 0; } и class ReceiveStream { virtual void accept_chunk(std::optional<std::string>) = 0; }. Вот хочется не изобретать велосипед, в виде выставленных наружу нестандартных интерфейсов, а потребовать от реализаций предоставления экземпляров чего-то стандартного, типа файловых потоков... но не такого перегруженного. Ну или концепты хотя бы какие-то стандартные есть?

std::streambuf?

очень и очень сложная штука для такой простой задачи.

Вот сейчас весь интерфейс выглядит вот так:

class snapshot {
   ...
   struct serialization_state {
       virtual ~serialization_state() {};
   };
   virtual std::pair<serialization_state *, std::optional<bytes>> serialize(serialization_state* state = nullptr) = 0;
   struct deserialization_state {
       virtual ~deserialization_state() {};
   };
   virtual deserialization_state *deserialize(deserialization_state *, bytes) = 0;
};

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

да, мы уже на С++20

(у нас корутины)

Мы тоже)

Есть ли гарантия в C++17 что пустой конструктор от std::string не пойдёт в аллокатор?

Проблема такая, что в проекте кастомный аллокатор для стандартных контейнеров, но хочется завести статический мембер std::string.

Является ли уб алиасинг чаром, когда он является signed? То есть char ведь может быть как signed, так и unsigned, однако стандарт ничего не говорит про signed char и говорит просто char
https://eel.is/c++draft/basic.lval#11.3

на сппреф ясно написано что чаром ок