Как эффективно хранить неопределенное количество разных типов данных?

Griboks, зациклился, потому что эти void хранить, когда в них можно хранить еще float - значительная потеря, особенно если такие случаи будут повторятся

Как эффективно хранить неопределенное количество разных типов данных?

Griboks,

Хранение данных должно быть эффективным - без лишних данных о других данных (то есть класс и т.д. для примитива - отметаем) и без пустот

, а тут чисто проблема variant/union

Как эффективно хранить неопределенное количество разных типов данных?

Griboks, конкретное ТЗ с вектором не выполнено. А то что вы сказали после "нет" вообще не понял причем тут это.

Как эффективно хранить неопределенное количество разных типов данных?

Griboks, потому что по определению double имеет длину в 2 раза больше float, float занимает 32бита.
Я привел пример. Но не с реальным кодом. Нет реального кода, потому что аллокатор еще не написал ответам выше.
Если уж совсем конкретно нужно, то - создайте аллокатор на основе аллокатора вектора, чтобы запись vector(float, double) стала верной, если он знает какие ячейки относятся к float, а какие к double.

Как эффективно хранить неопределенное количество разных типов данных?

Griboks, я не говорю о типах с незначащами нулями, я привел конкретный пример - float и double, float берет 32бита, double берет 64бита, это разные объемы

Как эффективно хранить неопределенное количество разных типов данных?

Griboks, это гипотетическая ситуация, когда на ЯП написано цикл каста, где идет рост данных например uint8_t, следущий цикл идет преобразование всех данных в uint16_t, следущий цикл в uint32_t и т.д.. Но при этом доступ к данным не прекращается для остальных потоков (данные для них обновятся только после каста). Допустим у нас был вектор с float и int, то такие преобразования для float нельзя применить, потому что float перемешен с int в 1 области памяти, можно доисать в конец буффер с кастом, но остается вопрос о float которые в результате каста уже не должны быть использованы, потому что есть double

Как эффективно хранить неопределенное количество разных типов данных?

Griboks, он бесконечный, потому что это цикл программы. А есть буффер или нет вряд ли повлияет на память программы на наличие дефрагментации. Меня интересует как я могу ее провести. Просто добавить буффер в конце и убрать ссылки на данные, которые были использованы для цикла, так себе идея. Образовавшеяся пространство может не соответствовать буфферу.

Как эффективно хранить неопределенное количество разных типов данных?

Griboks, у меня нет компиляции, как и число типов не ограничено (но описывается size_t). Меня интересует как удалять так, чтобы пустое пространство могло полностью уйти на новые данные. Потому что мой ЯП не может вечно выделять для себя память, особенно для циклов с преобразованием типов при случайном доступе (при условии, что данные не удалаются, а дозаписываются).

Как эффективно хранить неопределенное количество разных типов данных?

Griboks, variant имеет size_t для double, вектор с float x, y с таким типом может хранить 4 float, но хранит только 2 (чуствуете потерю в 2 раза?). Я не прошу литературу с непрерывной записью данных, а прошу литературу аллокацию данных, когда они разного объема.
Вектор уже использует аллокатор, но хранить он может только 1 тип, мне нужно чтобы была конструкция типа std::vector(float, double) вместо std::vector(std::variant(float, double)). Надеюсь это сделает мой вопрос более понятным. Треугольные скобки не отражались коррекно, заменил на круглые.

Как эффективно хранить неопределенное количество разных типов данных?

Griboks, я не сказал, чтобы было непрерывно в вопросе, я спросил как эффективно хранить информацию, чтобы не возникали пустоты и ненужная информация.
Про пример пустот я привел varian/union, которые имеют один размер но в целом создают повторяющиеся "дыры" которые нельзя убрать.
Если у вас есть литература, где описаны аллокаторы, которые хранят блоки разной длинны и при этом очень эффективно в плане дефрагментации и доступа к данным, то укажите их, пожалуйста.

Как эффективно хранить неопределенное количество разных типов данных?

Griboks, вы где видели программу, данные которой не удаляются? А по поводу данных... ну например float в double, но float лежит не в конце, так что его удалить нельзя, так что делать? хранить мусорный float? Это если без переполнения

Как эффективно хранить неопределенное количество разных типов данных?

Griboks, удаление данных путем "переполнение счетчика индекса стека"

Как эффективно хранить неопределенное количество разных типов данных?

Griboks, в вопросе пункт

Хранение данных не должно приводить к фрагментации.

Как эффективно хранить неопределенное количество разных типов данных?

Griboks, в каком способе? Какой тип аллокатора? Об удалении данных вы подумали? С записью данных нет проблем, они просто идут в конец

Как эффективно хранить неопределенное количество разных типов данных?

Я думаю, что ваш ответ и комментарии Евгения Шатунова будут ответами на мой вопрос. Большое спасибо за помощь!

Как эффективно хранить неопределенное количество разных типов данных?

Евгений Шатунов, lua, спасибо за совет

Как эффективно хранить неопределенное количество разных типов данных?

проблема в палке о 2 концах - либо плохая аллокация, либо неэффективность использования памяти под типы
в комментариях вопроса это показывается
а разница биты или не биты не важно, poor allocator тут как бы не помогает

Как эффективно хранить неопределенное количество разных типов данных?

Евгений Шатунов, я делаю это для своего ЯП, который не имеет компиляции, а исполняется за счет шаблонов исполнения которые описываются когда угодно. С типами также, если нужно описать новый тип - он описывается когда угодно, но до вызова функции работы с ним. А описание нужно, чтобы аллокатор умел работать с этим объемом. Создавая несколько экземпляров аллокатора можно работать с разными объемами, которые требуют типы. Они будут похожи, но будут отличаться только функцией удаления (зачем создавать разные указатели, если можно сделать статичную инкапсуляцию malloc (ну например так, я не совсем понял почему вдруг станет несколько указателей на malloc)). По поводу ХУ-проблемы: я не описывают проблему У для решения Х, даже если так, Y содержит все пункты Х. То что я предлагаю - это вопрос - будет ли такое решение верным для моего вопроса.
Если не надо создавать несколько аллокаторов, а просто работать с 1 экземпляром который знает все размеры и выделяет под каждый размер свои области, то это вообще корректно?

Как эффективно хранить неопределенное количество разных типов данных?

Евгений Шатунов,

Это снова что-то странное

: если мы создаем экземпляры аллокаторов со своими функциями (их число определено), разве не нужно писать для их экземпляров аллокатор, чтобы при множестве типов уметь быстро убирать экземпляр под неиспользуемый тип и при этом избежать дыр?

Как эффективно хранить неопределенное количество разных типов данных?

Евгений Шатунов, механизм должен уметь быстро заделывать дыры, когда в нем они образуются. У меня проблемы не с самими типами, а с дефрагментацией при освобождении данных. Будет ли разумно создать аллокатор для группы аллокаторов, которые будут выделять память и орудовать ею только для своих типов? Я хочу сделать систему, которая позволит максимально эффективно хранить и максимально быстро использовать данные, типы которых могут быть описаны прямо во время выполнения программы на основе уже существующих типов.