никак

Вчера ночью размышлял над своим игрушечным проектом, и полезли в голову странные идеи, как иногда бывает далеко за полночь. А именно: сделать memory_resource и аллокатор к нему, такой, чтобы любой allocator-aware контейнер можно было хранить на диске вместо RAM (необязательно сам объект контейнера, а именно его внутренние данные - то, что потребляет много памяти). Дисковую память отслеживать страницами/блоками/кластерами, непрерывность виртуальных адресов обеспечивать страничной организацией. Саму таблицу кластеров/страниц хранить в RAM.

Такое возможно сделать на std::memory_resource, и будет ли это работать как ожидается, т. е. прозрачно для контейнера и для пользователя этого контейнера хранить данные на диске вместо RAM?

как с помощью typeid получить нормально имя класса без всяких индетификаторов и неймспейсов?

Без сторонних либ никак?

Без сторонних либ никак?

Вчера ночью размышлял над своим игрушечным проектом, и полезли в голову странные идеи, как иногда бывает далеко за полночь. А именно: сделать memory_resource и аллокатор к нему, такой, чтобы любой allocator-aware контейнер можно было хранить на диске вместо RAM (необязательно сам объект контейнера, а именно его внутренние данные - то, что потребляет много памяти). Дисковую память отслеживать страницами/блоками/кластерами, непрерывность виртуальных адресов обеспечивать страничной организацией. Саму таблицу кластеров/страниц хранить в RAM.

Такое возможно сделать на std::memory_resource, и будет ли это работать как ожидается, т. е. прозрачно для контейнера и для пользователя этого контейнера хранить данные на диске вместо RAM?

Следующий шаг - cloud_vector с O(1) по памяти, который хранит свои элементы в облаке.

всем привет, надеюсь не слишком глупый вопрос: как в своей структуре сделать что-то наподобии variant? То есть объявить данные в зависимости от компиляции

всем привет, надеюсь не слишком глупый вопрос: как в своей структуре сделать что-то наподобии variant? То есть объявить данные в зависимости от компиляции

Вчера ночью размышлял над своим игрушечным проектом, и полезли в голову странные идеи, как иногда бывает далеко за полночь. А именно: сделать memory_resource и аллокатор к нему, такой, чтобы любой allocator-aware контейнер можно было хранить на диске вместо RAM (необязательно сам объект контейнера, а именно его внутренние данные - то, что потребляет много памяти). Дисковую память отслеживать страницами/блоками/кластерами, непрерывность виртуальных адресов обеспечивать страничной организацией. Саму таблицу кластеров/страниц хранить в RAM.

Такое возможно сделать на std::memory_resource, и будет ли это работать как ожидается, т. е. прозрачно для контейнера и для пользователя этого контейнера хранить данные на диске вместо RAM?

что значит в зависимости от компиляции? ifdef? зависимость на шаблонный параметр? variant?

Вчера ночью размышлял над своим игрушечным проектом, и полезли в голову странные идеи, как иногда бывает далеко за полночь. А именно: сделать memory_resource и аллокатор к нему, такой, чтобы любой allocator-aware контейнер можно было хранить на диске вместо RAM (необязательно сам объект контейнера, а именно его внутренние данные - то, что потребляет много памяти). Дисковую память отслеживать страницами/блоками/кластерами, непрерывность виртуальных адресов обеспечивать страничной организацией. Саму таблицу кластеров/страниц хранить в RAM.

Такое возможно сделать на std::memory_resource, и будет ли это работать как ожидается, т. е. прозрачно для контейнера и для пользователя этого контейнера хранить данные на диске вместо RAM?

ой, соре плыву. на этапе компиляции в зависимости от шаблонного параметра (просто в голове все перемешалось)