Griboks, вы просили конкретный код. С конкретным числом типов, с конкретными размерами. Не важно сколько типов и с каким размером будет создано и положено в вектор, если аллокатор способен работать с разными размерами. Я сказал, что решение проблемы У решит проблему Х, потому что мне нужны идеи для реализации (а в данном случае работа аллокатора через size_t). От вас я пока получил ответ: стек, который не поддерживает случайный доступ (а программа разве вся стек???), незначащие биты (от которых я просил меня избавить еще в вопросе), "задайте другой вопрос, а не этот".
Griboks, зациклился, потому что эти void хранить, когда в них можно хранить еще float - значительная потеря, особенно если такие случаи будут повторятся
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? Это если без переполнения
проблема в палке о 2 концах - либо плохая аллокация, либо неэффективность использования памяти под типы
в комментариях вопроса это показывается
а разница биты или не биты не важно, poor allocator тут как бы не помогает