Динамические структуры в shared-памяти

Да, удобно, спасибо. А вот у меня задача разместить в разделяемой памяти key-value хранилище, да еще сделать так что бы это хранилище синхронизировалось между несколькими хостами.

Вот в этом фрагменте:

	many_stacks(std::vector<std::size_t> sizes) :
		from_existing(ptr),
		can_be_shared({
			array(&stacks, sizes.size(), init_fn, sizes)
			}) {};

Откуда берется ptr для передачи в from_existing?

И в чем смысл передачи sizes по значению?

Вот это: (std::size_t)this, если я правильно понимаю, не есть хорошо, т.к. нет гарантий, что значение указателя, преобразованное в беззнаковое целое, уместится в std::size_t. Для таких целей, если не ошибаюсь, std::uintptr_t должен использоваться. Надеюсь, более знающие люди поправят меня, если я не прав.

Общее впечатление от кода вашей библиотеки (и ваших примеров здесь) стремнстранные. Приведение типов в стиле чистого Си вместо reinterpret_cast/static_cast, typedef вместо using-ов (при этом код на C++17), практически полное отсутствие комментариев.

Еще очень сильно смущает принятое вами решение по дизайну вашей библиотеки: вы заставляете программиста перечислять поля типа два раза:

	shared_stack(int max_size) : 
		can_be_shared({ 
			// Поля структуры
			field(&size, max_size), 
			field(&top_, 0), 
			// массив размера max_size, init_data 
			// инициализирует значения массива
			array(&data, max_size, init_data) 
			}) {}
      
  shared_stack(void* ptr) : 
		// Указываем, что создаём объект из уже созданного
		from_existing(ptr),
		// и передаём поля для подстановки указателей
		can_be_shared({
			existing_field(&size),
			existing_field(&top_),
			existing_array(&data)
			}) {}

Такое дублирование не есть хорошо, оно чревато ошибками в будущем, когда на проект приходит Вася Пупкин и правит код Феди Иванова. Вася наверняка забудет перечислить новое поле в каком-то из этих мест.

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

Ну и по тексту статьи: у меня после прочтения сложилось ощущение, что ваша библиотека берет на себя еще и заботу по работе с shared-памятью. Но оказалось, что это не так, вы лишь помогаете "размечать" блоки, которые кто-то в shared-памяти уже каким-то образом создал (как, собственно, и саму shared-память). ИМХО, это следовало бы описать в тексте.

поясните еще раз - shared память выделить нужно извне и синхронизировать доступ тоже ?

в чем смысл библиотеки - ускользает от понимания

много-процессорный пример был бы полезен )

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

Нужно из одного процесса в другой передать объект, состоящий из двух строк. Размеры и содержимое этих строк известно в процессе конструирования значения в процессе-продюсере.

Грубо говоря, в продюсере мне нужно что-то вроде:

class package {
  char topic_[];
  char payload_[];
public:
  package(std::string_view topic, std::string_view payload) {
    ... // Какое-то перемещение topic в topic_ и payload в payload_.
  }
};

А в процессе-консумере мне хочется получить что-то вроде:

class package {
  ... // Не очень понимаю что.
public:
  package(void * ptr) {... /* Какая-то магия */ }
  
  std::string_view topic() const { ... }
  std::string_view payload() const { ... }
};

А boost::interprocess не тоже самое делает? Там и аллокаторы уже реализованы

Если это не первоапрельское, то годный сборник undefined behavior в стиле си с множеством примеров как НЕ надо делать